[Vm-dev] Windows VM broken for ioShowDisplay
nicolas.cellier.aka.nice at gmail.com
Mon Nov 14 14:29:37 UTC 2022
I think that I found it.
There's potentially a GDI leak in getDpiSystem(), but it's not (usually)
used, it's just a fallback.
What solved the problem for me was to use DestroyIcon() rather than
because the cursor was created by CreateIconIndirect() rather than
Why it's different for others, I don't know, maybe there is no creation of
ARGB cursors, but just simple masks?
That may explain different behaviors across different images...
Le lun. 14 nov. 2022 à 14:44, Tobias Pape <Das.Linux at gmx.de> a écrit :
> > On 14. Nov 2022, at 14:17, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> > Hi Nicolas --
> > Hmm... we haven't touched that win32 platform graphics code in many
> years. It was not necessary to get that high-dpi stuff working.
> > Here are primitives you can try to disable:
> > DisplayScreen >> #forceDisplayUpdate (prim 231)
> > DisplayScreen class >> #actualScreenScaleFactor (prim
> > DisplayScreen >> #primitiveDeferUpdates: (prim 126) -- graphics will
> flicker then
> > DisplayScreen >> #primShowRect... (prim 127) + #primRetryShowRect...
> (prim 127)
> > Maybe this helps. My GDI objects are stable at about 20.
> The High-DPI-Code explicitly handles the multi-monitor stuff.
> Nicolas, do you use one window stretched among several monitors or do you
> move the windows
> completely from one to anotheR?
> I move the Squeak window from one screen to the other, always entirely
because they have different DPI/layout.
This motion generally scrambles the layout of my iconified Squeak windows,
they pile up instead of being tiled, but that's a minor problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev