Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slower performance in FMX when drawing to a TBitmap.Canvas compared to the form's canvas or TPaintBox #157

Open
peterbone opened this issue Sep 21, 2022 · 1 comment

Comments

@peterbone
Copy link

peterbone commented Sep 21, 2022

Using v3.4.1. I have an application drawing thousands of thick lines to test performance. It's an FMX app running in Windows 32-bit in release mode. I have the following lines in the project file.

GlobalUseSkiaRasterWhenAvailable := False;
GlobalUseSkia := True;

I have a TPaintBox and a TImage on the form. Drawing to the TImage.Bitmap.Canvas takes more than 3 times as long as drawing to the TPaintBox.Canvas. Is this because the GPU isn't being used when drawing to a TBitmap? With Skia disabled the timings are very similar for the TPaintBox and TImage (similar to the TPaintBox with Skia enabled). So without Skia the GPU appears to be used for both, but with Skia the GPU appears to only be used for the TPaintBox.

This is an issue because the main application I'm working on tends to do a lot of off screen drawing on TBitmaps for various reasons.

@viniciusfbb
Copy link
Member

hello @peterbone

It works exactly as you said. The graphic engine we made using Skia uses raster mode (CPU) on the bitmap canvas and GPU on the screen canvas. There are several reasons to adopt this way, one of them is to try to create a bitmap that can be used in background threads in a really parallel way, which doesn't happen in the standard FMX system because there is an internal global lock in TCanvas that locks the UI while the background thread draws to a bitmap. PS: it is necessary to change FMX.Graphics to take advantage of this feature of Skia while the Embarcadero does not implement the changes we requested.

I also want to point out that this slowdown does not occur on all machines, as there are machines where the raster has a very similar performance to the GPU.

Anyway, we plan to add new backends to Windows, and test new designs to improve overall performance in the future. But in the short term there is not much to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants