Graphics Contexts and Clipping

[Matthew Boulter]

I have written a little tool that given a Widget will draw a boundary and add information text for things like the vertices/height/width.

Not sure what I'm doing wrong but take for example in my image below.
The vertices text panel on the right, it includes contents of windows that are no longer there. When I took this screenshot I had minimised all windows except the target,

There should just be a white panel in top-right "1920 @ 176" and bottom-right "1920 @ 784" and slightly some of the "609" in the middle right. 

The rest should be black, the colour of my desktop wallpaper.

Do I pick IncludeInferiors or ClipByChildren ... or am I holding on to the GC too long, or something else?

Thanks in advance.
Regards, Matthew.

[Marcus Wagner]

I am sorry.  Can you specify precisely your problem. Seeing a blurred screen shot and gicen some coordinates does not enable me even to recognize what is disturbing.

[Matthew Boulter]

Apologies I have never tried attaching images to a Group Conversation.

This issue proves quite hard to capture. 

I have tried GIF recording, recording via a Team video.... but the visual artefact errors this thread is regarding do not manifest 
the same way were I not recording and still wrong, but in a different way. See the end of this email for an example of that.
Therefore the best I could think of is a set of 5 static image captures.

So in these images I am using my tool (the Query Object window). The first toolbar button switches it to a mode where I can hover over a widget
and it will highlight it in a red box with diagonal lines., that is the selected object. It will then traverse up that widget's family tree to find the CwTopLevelShell.

After that, once selected at any time, I can press the lightning bolt toolbar button and around the bounding box of the Top-level shell window.
It will draw a red box, print the x,y in each corner, width and height on each side and name/origin/width/height as a center label.

So below I have used my tool and selected the Workspace window.

Screen 1:    Before shot

Screen 2:    I pressed the Flash button and it draws the top level shell dimensions of the workspace.

Screen 3:    I move the workspace windows and then press the Flash button again, so far so good!

Screen 4:    I only move the Organizer window around and then press the flash button again

                    My flash render retains the organizer window that was there?

Screen 5:    This time I have minimized the Organizer window and also moved the Workspace window; and then pressed the Flash button.
                    My flash render retains the organizer window that was there in screen 3, but the text has changed.

Seq 1:  

Seq 2: 




Seq 3: 




Seq 4: 
Seq 5: 

I hope this is has been clearer.

Thanks for your time.

/Matt

---------------------------------
That example of the weird GIF recording different effect - though I dont care about this as I do not intend to record what I am doing, It just irritated me I couldnt record my problem lol :D
GIF --> Normally as I move my cursor it draws a red box with diagonal lines for the "widget under pointer" only if I am not recording

[Marcus Wagner]

Hi Mathew, 

sorry for my delayed response. I was and I am still not able to respond adequately in time. Thank you for your additional material.

I just pick up first facts (i hope I deducted them correctly) from what I saw having a short glimps.

Environment is Windows (unknown version), VASt seems to be 8.6.3 -> 2005.

This is important for the following background information and arguments to follow.

Since then (2005) MS invested a lot in technically support of high resolution and multiple screens, with significant influence on frameworks using that, beginning visibly as of Windows 8 (2014?).

OTI initially constructed (ancestor of VAST) the common widget hierarchy based on Motif and already then (1990ies) was confronted with a lot of gaps between Unix, OS/2 and Windows 3.11 / NT.

Other Smalltalks in the 90ies followed another approach, e.g. integrated Windows widgets directly. (Side effect: severe implications when migrating a ST application to other OS environments).

VisualAge and VAST versions kept the gap (between Windows and CommonWidgets based on Motif architecture) as narrow as possible - and Instantiations enhanced the tool representation significanty (VA Assistant and Scintila to be mentioned here). Instantiations also alternatively offers its own framework (windows builder, business graphics and the like) still following this old tradition.

There is a significant gap between Motif based origins and Windows widgets, in particular since the support of high resolution and muitiple screens: the underlying coordinate systems.

Initially, under Motif, the top left corner of the single screen was 0@0. Anything which has to be shown extended to the right or downwards, so x@y, x>0 to the right and Y>0 downwards.

Negative coordinates did not appear, and the screen with dimensions w@h (w= width, h = height) was the limit, and there was one resolution being valid over the whole visible area.

This does not hold any more (see my post scriptum below). 

Windows coordinates can be negative and the spanned virtual desk top can have holes (between adjance multiple screens) and can have different resolutions though being able to place a particular window so that its parts are simultanously presented on different screens with different resolutions.

Already at that beginning in the 90ies, Windows labels did not follow this coordinate scheme (of Motif). 

Coordinate 0@0 is the left top corner of the widget workspace below the label/title bar, which is not counted -> under Windows, there exist at least three different coordinate systems in parallel. There is code in OSShell to adopt (Motif coordinates) to this. Your red frames with coordinates follow the Windows Widget coordinates, not the desktop / workspace coordinates in use for clipping. This is one hint to folllw.

Already that gap has been closed (and this was valid in VAST 8.6)  by OTI and later VASTs, by placing such a window not at 0@0 to go to the top left corner, but to x@y with x being the thickness of the left windows frame thickness and y being the height of the title bar (which otherwise would have been cut off and invisible). 

But this issue reopened under Windows 10 and is still unsolved (I patched this for me only). This problem appears now starting the Transcript under Windows 10/11.

I explain this because the coordinates within common widgets are OS independent (and you see only these in ST), e.g. claim to be valid under Windows and under Unix, Linux, ... but they are not any more.

They have to be mapped to the underlying actual system. This is the task of the (OS dependent implementation layer of) the OS widgets hierarchy below the common widgets.

Introducing high screen resolutions and multiple screen made things even more complicated. 

A typical effect placing a window to (Motif) coordinate 0@0 under Windows is, that the title bar (with negative coordinates) is placed to a possible existing other screen above, however potentially covered by the traditional tool bar (I saw one in your screen shots) with icons and thus such a placed window cannot be manipulated as usuall, as the its title bar and tool menues are invisible and unreachable using common mouse clicks. -> under motif, such a window is perfectly visibly placed at the left top corner, not so under windows. it is placed on my laptop, partially hidden and cut off and tool bar unusable).

I wanted to give you this before even diving deeper to find a solution to your particular problem. 

First the common widget hierarchy you seem to use is totally out of date. 

All later enhancements here to adequately cover problems introduced by support of multiple screen / resolutions under Windows are missing. 

And if you are working near to the OS implementation (hovering, drawing, clipping indicate me that ou want to do so) you must be aware of the hosts coordinate systems, which did change significantly under Windows since then.

So the next step is to narrow things down: what OS and what VAST version is in use in development and what OS and version is the target environment.  

In the most complex situation we have to find a solution which adopts dynamically to the currently running system underneath. 

And as you diagnosed already: that solution was not on the horizon 20 years ago (VAST 8.6). 

Now wonder about misfunctions happening now.

Any solution here has to be aware of these nasty details.

Perhaps we find s.th. cheap if your problem can be narrowed down to a particual environment, not necessarily considering the complexity of all already exsting environments in the universe.

I will answer again after studying your new material.

-Marcus

PS: I am curious about the announced Linux GTK support. This opens a new front of complexity here.

PPS: I am writting this using two screens wired to a laptop docking station -> three screens (VAST 13, Windows 11). 

Screen 2 left                 Screen 3 right

         Laptop Screen 1 below

All of these monitors show a tool bar -> reducing the three work spaces, as shown by their rectangle coordinates below

Here some ST traces to give you some impression of the underlying problems

Right screen

DPIScaler activeDisplayArea 1034 @ -2161 corner: 4874 @ -81

DPIScaler activeDisplayAreaScaled  1034 @ -2161 corner: 2954 @ -1121

DPIScaler  translateToActiveDisplay:  0@0 1034 @ -2161

OSShell activeMonitorInfo

*OSMonitorInfoEx {

cbSize: 72

rcMonitor: *OSRect {

left: 1034

top: -2161

right: 4874

bottom: -1

}

rcWork: *OSRect {

left: 1034

top: -2161

right: 4874

bottom: -81

}

dwFlags: 0

szDevice: '\\.\DISPLAY3'

}

Left screen

DPIScaler activeDisplayArea  -2806 @ -2160 corner: 1034 @ -80

DPIScaler activeDisplayAreaScaled  -2806 @ -2160 corner: -886 @ -1120

DPIScaler  translateToActiveDisplay:  0@0  -2806 @ -2160

OSShell activeMonitorInfo

 *OSMonitorInfoEx {

cbSize: 72

rcMonitor: *OSRect {

left: -2806

top: -2160

right: 1034

bottom: 0

}

rcWork: *OSRect {

left: -2806

top: -2160

right: 1034

bottom: -80

}

dwFlags: 0

szDevice: '\\.\DISPLAY2'

}

Laptop screen

 *OSMonitorInfoEx {

cbSize: 72

rcMonitor: *OSRect {

left: 0

top: 0

right: 2560

bottom: 1440

}

rcWork: *OSRect {

left: 124

top: 0

right: 2560

bottom: 1440

}

dwFlags: 1

szDevice: '\\.\DISPLAY1'

}