On Mon, Apr 30, 2007 at 02:26:37PM +0300, Eero Tamminen wrote: > Hi, > > Daniel Stone wrote: > >>> On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote: > >>> You mean, modify every single drawing X request in the X protocol so it > >>> contains flags, meaning that we have to change every drawing-related > >>> function in -- on average -- ten (at least) places in the server > >>> codebase, rendering us incompatible with the standard X server codebase, > >>> as well as the X protocol? > >>> > >>> Plus, the update is done long after the drawing information has been > >>> discarded. > > Yes, this would imply that the flag is propagated to the FB update > structs (i.e. minor implementation detail compared to adding it to GC > which is part of the standard X API :-)).
The point is that, as it stands, the GC has no bearing on it. All drawing is done to the main screen pixmap. A timer runs to check the damage on the pixmap, and flush the affected areas: i.e. it's not strictly connected to the rendering callchain, but runs as a side-effect thereof. > >>> 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. > > 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.
signature.asc
Description: Digital signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
