[maemo-developers] Xsp pixel-doubling solutions for Nokia 770?
From: Daniel Stone daniel.stone at nokia.comDate: Mon Apr 30 14:26:11 EEST 2007
- Previous message: Xsp pixel-doubling solutions for Nokia 770?
- Next message: Xsp pixel-doubling solutions for Nokia 770?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20070430/29b6175c/attachment.pgp
- Previous message: Xsp pixel-doubling solutions for Nokia 770?
- Next message: Xsp pixel-doubling solutions for Nokia 770?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]