[M3devel] strange problem w/new Image/ImageInit

Mon Aug 11 21:23:17 CEST 2008

Jay:

I have been experimenting quite a bit and I've come up with some "new old" information.

I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.

If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.  

The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.

Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.

The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.

All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.

Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.

I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.

Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?

Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 2:41 PM >>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.  

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay

________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit

Jay:

I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.

Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?

Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay

> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080811/ead5acd5/attachment-0001.html>