QuickGFX feature feedback

AmiBroker
#1

Just released AmiBroker 6.40 features new experimental feature QuickGFX that is intended to bypass entirely Windows GDI and provide new levels of performance.

This thread is intended to collect feedback about QuickGFX including performance measurements (QuickGFX timing vs Windows GDI) and any outstanding issues.

ABOUT QUICKGFX

QuickGFX technology to render charts way faster than before. Complex charts show anywhere from 10x...100x performance improvement. Yes, that sounds unbelievable but the formulas that were posted in this very thread under new QuickGFX rendering technology show decrease in rendering time from 350ms down to 8ms (that is 43 times faster!!! but I have seen even better gains in some cases)

This feature is experimental as it is not fully implemented yet and may not support each and every style yet but I decided to bring it already in 6.40.0 RC so you can test it on your end and report any issues (as there undoubtedly be some issues as it is completely brand new code that wasn't tested for 20+ years like the old code was).

Also note that this feature is available only in registered version and only to users who licensed PROFESSIONAL edition. This is yet another Professional-edition extra.

ISSUES FIXED ALREADY IN VERSION 6.40.3

  1. New line spacing in Titles ("\n") in QuickGFX mode is greater than in Windows GDI.
  2. (styleHistogram + styleThick) lines disappear with negative values and certain zoom levels.
  3. styleThick implemented (solid lines only)
  4. width > 1 implemented (solid lines only)
  5. styleDashed implemented

FEATURES/STYLES NOT IMPLEMENTED YET - to be implemented in upcoming versions

  1. clipMinMax is not supported
6 Likes
AmiBroker 6.40.0 RC released
AmiBroker feature
#2

You can give it a go now: AmiBroker 6.40.0 RC released

image

2 Likes
GDI render Windows 7 vs Windows 10
#3

Once you try it out, please post your timings here (GDI vs QuickGFX) so we get results from various systems. Please also post screen resolution, as number of pixels (size of bitmap) plays important role in comparing performance.

1 Like
#4

QuickGFX mode. Problem with "\n":

Title=Title+"\ntest";
Plot(10,"\ntest",colorRed,styleOwnScale,Null,Null,0,0,1);
Plot(10,"\ntest2",colorRed,styleOwnScale,Null,Null,0,0,1);

newline

without QuickGFX:
newline2

1 Like
#5

You can't add to uninitialized variable (Error 29 variable used without having been initialized)

Other than that, I can see that new line spacing is different. This can be considered as minor issue, I added this to to-do list.
I am more interested in TIMINGS.

#6

Timings are wonderful. Fast tests, LCD 4k 3840x2160 Windows 7 from 110 ms to 10 ms, Windows 10 from 220 ms to 23 ms.

styleThick not working for styleLine, styleBar, styleDots and working for styleHistogram. The same with last parameter (width) of Plot().

1 Like
#7

Yes, styleThick isn't implemented yet. I have added this and previous report to first post that lists all outstanding issues and not-yet-implemented features.

Thank you for the timings. I was specifically curious about your results because you were using 4K resolution exclusively and Windows GDI was slow on your end. It is interesting that you are still getting faster draws on Windows 7. The only reason for this can be memory (RAM) bandwidth, as QuickGFX executes exactly same code that writes directly to bitmap in RAM without any Windows OS dependencies.
If you try with PlotVapOverlayA you should see even bigger gains in speed.
You should also see better parallelism than with GDI. QuickGFX does not have any synchronization roadblocks (such as critical sections/semaphores/locks) like Windows GDI has, so QuickGFX should scale much better with multiple threads.

1 Like
#8

Quite frankly when I first ran my code I could not believe my eyes and I really started to doubt if I get those numbers right. After checking this over and over again and getting same surprisingly good results I started to wonder: what the hell is wrong with Microsoft? Really Microsoft? Couldn't you do any better? It should be impossible to get 10x gains if Microsoft did their job right.

4 Likes
#9

And don't forget about PlotShapes() :wink:
There is also problem with dissapears plots and negative values.
Small window:
dissapearsNegativesmall1
Medium window:
dissapearsNegativemedium1

Negative values, small window:
dissapearsNegativesmall

Negative values, medium window:
dissapearsNegativemedium

#10

For them the most important thing is the new useless taskbar (Windows11), the new Paint...but not the optimization.

ps.
I'll have a new assignment for you. Memory management :smiley:

#11

When reporting problem please always include formula that reproduces the problem. Really it helps tremendously. For you it is just copy paste of the code that you already have (1 second). For me is guessing "what the heck was the formula that produced this" (minutes? hours?). So pretty please with sugar on top please always post formula.

#12

Yes, but it's a quite complex formula (with sparse) and I'm very tired today. With free time I'll add some afls.
And I forgot. Thanks for your work! :clap:

#13

I would like to hear feedback (esp. timings) from other users as well.
It is important because:

  1. I need to know if speed-ups are achievable everywhere (regardless of hardware)
  2. I need to know if anyone sees regression

The thing is that developing it further (which is time consuming) makes sense only if gains are significant. It is not worthwhile if gains are 10-20%. If speed gains are >10x across the board I can invest more time to it. Simply it is lots of work and I have to be sure it makes sense for everybody, not only one or two persons.

#14

Without Quick GFX:
image

With Quick GFX:
image

Without Quick GFX:
image

With Quick GFX:
image

I noticed Style Think is having problem as mentioned above with Quick GFX:

Without Quick GFX:
image

With Quick GFX:
image

A significant improvement in performance GDI 14.7ms VS Quick GFX 4.8ms

Screen Resolution : 1366 x 768

Thank you Tomasz.

2 Likes
#16

3840x2160, a lot of styleDots, 400 000 bars. I have 10 charts with this formula, and I frequently get (with old GDI render) Warning 901.

Old GDI Render:
770ms

New cosmic QuickGFX!:
20ms

#17

Biggest gains can be observed for charts that really plot a lot (>100ms GDI rendering).
If chart is simple and only uses under 5ms in GDI there is hardly any room for improvement since there is some minimum constant time that is required in both modes to allocate a bitmap.

To see the improvement, you can use "killer-formula" (with 200 Plot() statements):

// graphic performance killer benchmark 200 Plot()s
for(i = 0; i < 200;i++)
{
  Plot( C+10*i, "Close", ColorHSB( i, 255, 255 ), styleLine | styleDots); 
}

On my end it takes 843ms with Windows GDI and only 15ms with QuickGFX

1 Like
#18

Good AFL for testing.

For 60 000 bars: 1015 ms -> 25 ms
but
For 400 000 bars: 1020 ms -> 537 ms

#19

For 400K bars, your GDI result is incomplete because it terminates execution after 1 second spent in GDI. So as soon as it hits 1000ms mark, you get a Warning 901, GDI time is under-represented and graphics shows output of only some (like 5-10) Plots()s.

1 Like
#20

You can increase the Warning 901 time limit from default 1000 ms to any value of your choice using registry key

HKEY_CURRENT_USER\SOFTWARE\TJP\Broker\Settings\ChartRenderTimeout

(DWORD value) rendering time limit in ms. If you set it to 10000 the limit will be 10s.

Note that this setting is effective only when multithreading is enabled and value from registry is only read at program startup. If you change it during execution it won't affect anything. If multithreading is disabled, then timeout will be fixed to 500ms.

After you increase the limit, you can try GDI again with 400K and it is likely to use > 5 sec to render the benchmark. Please try.

2 Likes
#22

I set 10000.
4100 ms -> 600 ms :smiley: