[etoys-notify] [JIRA] Updated: (SQ-201) Etoys resume instance has forgotten display mode scaling

[tracker at squeakland.org]

     [ http://tracker.immuexa.com/browse/SQ-201?page=all ]

timothy updated SQ-201:
-----------------------

    Priority: Optional  (was: Eventual)

> Etoys resume instance has forgotten display mode scaling
> --------------------------------------------------------
>
>          Key: SQ-201
>          URL: http://tracker.immuexa.com/browse/SQ-201
>      Project: squeakland
>         Type: Bug
>   Components: etoys-sugar
>     Reporter: team
>     Priority: Optional
>      Fix For: etoys 4.1 and showcase - june 2010
>  Attachments: OLPCVirtualScreen-zoomInorOutToatvanishingPoint.st
>
>
> From TRAC icket #9238 (FGrose, february 2008)
> Steps to reproduce:
>    1. launch Etoys
>    2. adjust display mode to 'Display actual pixels'
>    3. click 'Keep a current project' (should be 'the' current project)
>    4. click 'Stop and Quit Etoys'
>    5. resume your project from the Journal 
>     * notice that the display mode is 'Scale to Fit', the apparent default 
> (observed on Etoys 4.0 update# 2201, on SoaS-200902061045.iso)
> Attachments
> OLPCVirtualScreen-zoomInorOutToatvanishingPoint.st (1.2 kB) - added by ohshima 10 days ago.
> (bert) I'm not quite sure if this is a bug or expected behavior. The scaling mode is not saved in the project file, but on loading a project an appropriate mode should be chosen. Basically, if you load a project that was saved at the same (unscaled) resolution as the Etoys window has now, scaling should be disabled.
> Possibly what you see is that if we detect to run under Sugar at a resolution other than 1200x900 we assume it is an OLPC emulator so switch on the scaling to 1200x900, so projects saved in emulation are compatible with the XO hardware.
> That said, release 4.0.2205 does tweak the scaling behavior - could you retest?
>  
> (FGrose) After <Alt,> help... update code from server : 4.0.2206
> I noticed that the enableVirtualOLPCDisplay preference is set to true and is bolded, indicating it is a project-specific property.
> While running SoaS from a USB flash disk on a 1280x1024 monitor, I have the Display Actual Pixels option available, which I prefer using, because it sharpens the image on my screen. So, I want to return to that mode globally rather than on a by-project basis.
> Assuming there is a globalDisplayMode property initialized to 1200x900 scaling, would the following projectOpen logic be reasonable? (in LargeTalk:)
> when the ScreenSize > 1200x900, then
>    use globalDisplayMode (it was set by the user as preferred)
> when its = 1200x900, then
>    use 1200x900 (No Scaling)
> when its < 1200x900, then
>    use 'Scale To Fit'.
> Thanks for all your good work!
> (FGrose) I've tested a bit more with the 1280x1024 monitor, and found that upon returning to the Previous project, if the displayMode was Display Actual Pixels, the image goes through a Scale To Fit stage, before returning to the Actual Pixel size.
> The vertical bands outside the Actual Pixel image are not cleared, and so polluting the view.
> For example, the viewer tab for the car is left on the right border of my screen as a dead artefact.
> Point me to the relevant code please, and I'd like to look deeper into this.
> Thanks!
>   
> (bert) Well the logic is scattered all over the place. You could browse references to OLPCVirtualScreen (which probably should be renamed to VirtualScreen now) but maybe Yoshiki should explain what the current logic is (he tweaked it quite a bit after Andreas' initial implementation).
> We have quite a few cases - what to do on startup, what when entering a project, what when the window is resized, depending on if we run in Sugar, or in the Browser, or stand-alone, what the saved project size was, what the window size is, what preferences are set etc. And on top of that we'd like to provide the best experience for everyone and ensure projects are nicely exchangeable between platforms, but optimized towards the XO which has both the largest user group and is the least-performant machine (so we need to avoid scaling there if at all possible).
> Given that we have been discussing this for a long time I have the impression the problem is over-constrained and we need to compromise, but how to balance the trade-offs is still undecided.
> (yoshiki) I've tested a bit more with the 1280x1024 monitor, and found that upon returning to the Previous project, if the displayMode was Display Actual Pixels, the image goes through a Scale To Fit stage, before returning to the Actual Pixel size. The vertical bands outside the Actual Pixel image are not cleared, and so polluting the view.
> I need to try it by myself. A big display is not always available to me, though. So, from your description, the end-result is "ok" but the pollution is the problem?
> OLPCVirtualScreen>>zoomOut: should be the only place, and the second #forceToScreen should have cleared it, I thought. The boundingBox used in #forceToScreen is incorrect, maybe?
> (FGrose)
>     So, from your description, the end-result is "ok" but the pollution is the problem?
>     Yes, this is a problem I noticed while studying the scale-setting behaviour.
>     OLPCVirtualScreen>>zoomOut: should be the only place, and the second #forceToScreen should have cleared it, I thought. The boundingBox used in #forceToScreen is incorrect, maybe?
>     Haven't looked at the code yet, but this sounds likely.
> (yoshiki)
>     * attachment OLPCVirtualScreen-zoomInorOutToatvanishingPoint.st added
> One trouble is that it is ok on Windows but only shows up in X.
> The issue is in OLPCVirtualScreen>>#zoomIn:orOutTo:at:vanishingPoint:.
> If the code looks like the attachment, at least the pollution problem is solved. It still does the extra refreshing display, which is still annoying.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://tracker.immuexa.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira