Hi,
Daniel Stone wrote:
>>>>> Sure, but that's mainly because pixel-doubling is a non-portable hack
>>>>> (doesn't exist in other products, doesn't exist on desktops, may not
>>>>> necessarily exist in future products). It's not a hack because of how
>>>>> it's implemented, but just by its very nature.
>>>> Hmm, I would not call a feature in HW a hack. It's just a feature of
>>>> particular hardware which can be utilized.
>> Nothing says that the *API* should be limited to 2x.
>> That's an implementation limitation, you don't need to
>> design an API around the limitation.
>
> Hence, XRandR. The only thing worse than designing a bad API, is
> designing _another_ API.
Hm. I think the API on Desktop for scaling window content is OpenGL.
;-)
>>> The entire concept is a hack around games not running quickly enough in
>>> full resolution. Specifying that pixels must be exactly _doubled_ is a
>>> hack around both the performance issues and a lack of resolution
>>> independence. Apparently an important one, if you happen to like SDL
>>> games, but a hack nonetheless.
>> Well, this is broken on the desktop too.
>>
>> There are also Desktop programs (games) which change screen resolution
>> and when they for some reason freeze and I need to kill them, the screen
>> is left in wrong size. It should be possible for these X clients to
>> state that the new resolution is kept only while the client is connected
>> and once it disconnects, the normal (default) resolution is restored.
>> And this should be the default I think (it's easier to change settings
>> programs to have "permanent" flag than change all programs using
>> resolution changing).
>
> If you can come up with a policy that works in corner cases, you're a
> genius.
It's evil that games change screen resolution, system changes
should be controlled by system software instead of random apps.
If it's enough that the whole screen is scaled instead of a window or
specific update, for Maemo the XRandR approach could be joined with
my earlier proposal.
I.e. if window has certain property (say geometry=320x200), the window
manager could use XRandR to switch the screen resolution when that kind
of a window is on top/focused/fullscreen(ed). When the window is not
anymore focused/top/fullscreen or is closed, the previous/default
resolution is restored. This way banners above the window wouldn't
get the resolution changed (banners don't take focus), but dialogs
(like power menu) would.
Do you see any problems (besides getting these changes to Matchbox and
SDL after adding XRandR support to Xomap)?
- Eero
<joking>
Any chance of getting this into EWMH spec?
</joking>
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
