Jump to content

Markus Kinzler

Moderators
 View Profile  See their activity

  • Content Count

    559

  • Joined

  • Last visited

  • Days Won

    6

Posts posted by Markus Kinzler

  1. Posted

    Not really. OpenGL isn't as good as Vulkan and MoltenGL isn't free as MoltenVK.

     

    Now FMX uses:

    DX11 on Windows, OpenGL on macOS (and Linux inofficially), OpenGL ES on Android and iOS.

     

    Instead of a new implementation:

    DX12 on Windows, Metal on macOS and iOS, Vulkan on Android and Linux it would be better to concentrate on one solution.

     

     

     

    • Like 1

  2. Posted

    Quote

    At this time FMX for mobile devices is rendering via OpenGL. OpenGL in iOS however is deprecated. I don't know the situation in Android, but for iOS this is really good news and leads to faster rendering in Delphi apps.

    The better thing would be switching to Vulkan. One solution for all platforms (Windows, Linux, Android: native, macOS and ios via MoltenVK (included in Vulkan SDK).

    • Like 3

  13. Posted

    Quote

    Imagine what could have been achieved on Windows if all the resource that was used on the new platforms had been spent on Win32 and Win64? 

    Because they see no need for impovement here, i don't theink the product would be much better.

     

    Quote

    Sometimes it takes strength to say no to some customers. 

    This wouldn't change much. There's seems no need to invest for earning money. Business isn't to create tools but only to earn more money with less effort.

  14. Posted

    But you cannot survive just with legacy! The expenses for maintenance would be copable when development would be steady in cadence with the plattforms. It is a great problem when there is the need for "reaction" in hassle.

    EMBT have ti build a homogenous platform with one front end (compiler) per language and one back end per platform. The development should be decoupled ( compiler, code gen, runtime, ide).

    • Like 1

  15. Posted

    Quote

    In latest roadmap it was newer scheduled for 10.3, but for some 10.3.x update 

    Prior to release of 10.3 it was scheduled for it.

     

    Quote

     

    New Platform Support

    Platform support is key with a multi-platform framework like FireMonkey. We know that Android 64-bit support will be mandatory by the summer of 2019, and are working on plans to ensure our customers can meet this requirement next summer. 

    One roadmap change you may notice compared to the September 2017 roadmap is that we removed macOS 64-bit platform support from the initial 10.3 release.

    This doesn’t mean that we don’t think macOS 64-bit is important. We removed it from the 10.3 release to focus on providing more quality and stability for the other key features that are in flight. With that said, our intent is to provide support for macOS 64-bit, including support for targeting the iOS 11 (and iOS 12) simulators, in a follow-on 10.3.x release. We know that developers looking to target the macOS App Store or leverage 64-bit APIs require macOS 64-bit support.

     

    image.thumb.png.17db7d490aa7157722d1204da790345a.png

    • Thanks 1

  17. Posted

    Quote

    Although macOS 64 would be nice to have, but only very few seem to use it really.

    But the next version of macOS doesn't support it anymore. macOS mojave juust warns when starting 32 bit apps.

     

    Quote

    For Android I would assume there is much more interest, and failing this deadline would be a bigger problem for Embarcadero.

    In this case "only" the distribution in the play store is affected. In macOS the apps will stop working!

    • Like 1
    • Sad 1
×