On 18 May 2021, at 08:40, Manolo wrote:
> 
> @Ian: I would like to be sure you measure the current proposal is meant to account for the findings you have reported.
> With it, GDI+ would be used only to draw circles, arcs and oblique lines, so that the vast majority of FLTK drawings
> are unchanged. I also stress the test/doublebuffer program is very artificial in that each line gets drawn 10 times.


OK - first off, I don't want to cause any upset, and I know you have done a huge amount of work to get the GDI+ working as well as it does, but I have to say I’m really not keen on it, and would be very uncomfortable about it being made the *default* build choice. I’m fine with it being a choice.

It does affect my build quite badly, in some cases and/or on some machines, and in any case it “feels” a bit more sluggish to me, on all my tests.

I can’t post my actual code, and I acknowledge that test/doublebuffer is unrepresentative (though it does show the effect quite well[1]) but here’s an simple test we can all try at home.

On a Windows build of the GDI+ branch, run the test/unittests program and resize it to a large window, then select the “schemes test” tab, and there select the “plastic” theme (plastic because it seems, for me at least, to be the worst case...)

Now click on the lower right corner and start dragging the window corner about to resize it - it will redraw as it resizes. 
Well, with the “plain” GDI build it redraws for me pretty much as fast as I move the mouse.
With the GDI+ build it really does not - it updates sporadically and is always a way behind where the mouse pointer has got to.

Again, this is a somewhat artificial test, but I think it shows the speed difference in quite a clear way. I do not know what others will see when they try this on their machines though... indeed I’d be interested to hear!



>  
> If all windows were GL windows, could we just render “everything” via GL and get h/w accelerated rendering pretty much on all hosts that way? 
> That would be achievable completing the implementaton of the Fl_OpenGL_Graphics_Driver class  which is now only sketched.

Hmm. OK.
I doubt I have the skills to make that work but a version that used a GL or EGL backend for all rendering might be a “one size fits all” solution across multiple platforms (including Android?) 
I do not know, though.



[1] - I tried to screen cap a video of test/doublebuffer on my HP laptop, and the video doesn’t really show the effect; it doesn’t look like what was on the screen at the time. This, in itself, might be a clue as to what’s going on. I’m guessing it is something to do with the drawing blocking on frame-synch to prevent tearing or something, and that might also explain why double-buffered windows exhibit the effect significantly less.


-- 
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/54A14B4C-C8B8-41FE-A6A9-65C603B90ED9%40gmail.com.