For a long time, I have worked on Mac , but compiled for Windows on a windows box using Xojo 2015.
The app draws to screen while the mouse is held down, by calling invalidates.
In Xojo 2015, all works fine.
But if I compile for Windows using the same source, using Xojo 2018/2019 etc on my Mac,
the screen updates in the resulting app just dont work
I can get a full window refresh to work, but invalidates seem to get ignored.
Even changing a listbox row fails to indicate the selected item (would have used background or celltext events to paint)
Im fairly sure this is from the switch from GDI to Direct2D.
I had this kind of trouble way back in 2015 - didn’t get to the bottom of it then, and have delayed updating the windows compiler since .( If it works, dont fix it)
I dont yet NEED to switch, thanks to Microsoft, but I could really do with a Xojo for Windows that works ‘properly’
Any clues as to what I might be doing wrong here?
Surely calling invalidate should do the trick?
Dozens/hundreds of refreshes would be way too slow
The general stuff that is happening while the mouse is moving is this:
//copy work in progress image to bufferpicture
bufferpicture.graphics.drawpicture offscreenpicture,0,0
//tell the visible canvas to paint itself
//it copies bufferpicture to the screen, then adds ornaments
maincanvas.invalidate 0,0, maingrid.width, maingrid.height , false
edit: probably significant…
Compiled using Xojo 2015, it uses 109Kb memory when running.
Compiled using Xojo 2018r3, it uses 2.5Gb
Something not right here…
Are you using invalidate in a paint event?
Good thinking, but not as far as I can tell. I will see if there is anything that might do it indirectly.
(More: currently trying Xojo 2018 in Windows. Xojo itself is now up to over 2Gb just starting the code up in debug. Before any painting begins)
More recent Xojo versions, and so 2018/2019, do not like paint called from outside a graphics object. This is paid to the framework required for most-recent macOS versions.
So, if you want to paint something, call the GraphicObject.Paint event from outside.
//copy work in progress image to bufferpicture
bufferpicture.graphics.drawpicture offscreenpicture,0,0
//tell the visible canvas to paint itself
//it copies bufferpicture to the screen, then adds ornaments
maincanvas.invalidate 0,0, maingrid.width, maingrid.height , false
These paint events needs to be moved into their respectively graphic objects,
with a GraphicObject.invalidate added to their current location.
That needs variables set to “Do this paint command with the following GraphicObjects.Invalidate command”
Thanks.
Unfortunately, I cant understand what you wrote, but Im sure you are saying
‘Do not draw into graphics from OUTSIDE the Paint event’
instead, draw to the graphics only from inside a Paint()
Thats been the case for many years, and I already do that.
Its not that.
At the moment, I am seeing two main issues/causes
1/ The memory used by the running app using the exact same code has soared from 150K to over 2Gb. There is no reason for this that I can see, other than maybe Direct 2D instead of GDI. If so, I can do nothing about it.
2/ the main window’s paint event is being repeatedly called. I am struggling to work out what the reason is, as this is not the case when compiled by Xojo 2015
A paint event doesn’t have a 'reason I happened / sender ’ parameter, and the call stack and profile logs don’t tell me either.
I got slight improvement by fudging the paint event so that it doesnt run within 5 ticks of the last paint, but that is a horrible hack I would rather avoid.
Im also seeing cefsubprocess running. This must be Xojo… I can see cef libraries being bundled.
Drawing to a picture then painting it when you need it is a perfectly valid method of drawing in xojo.
Check for recursive paints, a system was introduced to limit this a while back to stop people falling foul of unknowingly causing a paint from inside a paint.
Have a look inside your canvas paint event to make sure that it can’t cause another paint of itself either directly or indirectly (e.g. by changing a property of itself or something that is embedded in it).
Cefsubprocess will be there if you have an htmlviewer in the project with the renderer set as webkit.
While perfectly valid, it’s not recommended if you can avoid it. This applies more to the Mac than other platforms though. The graphics object passed to Paint is able to do sub-pixel rendering on the Mac, which has an effect on how text is rendered. Text will be smoother as a result. If I recall correctly, drawing operations are faster too.
There are reasons why you’d want to maintain your own cache, but the old rule of always doing so is out the window. Now it’s the opposite: don’t use a buffer unless you absolutely need it.
Are you serious, is this documented somewhere?
I can’t seem to find anything. I had an old blog post (if I recall correctly) showing off the difference, but since the old RS blog is gone, I think it’s gone too. The good news is that since Mojave, subpixel rendering is disabled, since most Macs run on retina screens. I imagine the performance difference still exists, but I’d have to setup a test project to confirm.
Sorry for my wording, you interpreted it correctly.
Nice to read you’re already working like that.