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 :-)). > >
X extensions can add additional properties to GC's, Pixmaps's etc and this functionality is a part of the standard X API. > >>>> IOW, no. (Also, bear clips in mind, which complicates things.) >>>> >>> Well more likely something like this would be implemented as a >>> additional flag in GC, right? But I think it would be nicer to just have >>> a special call for 2x-blitting, this would be more sense. >>> >> Sure, but the update is only done after the final screen pixmap has been >> retouched, by which time the GC is also long gone. >> >> >>>> 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. > > > >> 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). > > This is true, I guess many people suffer from this but it's just not agreed where to fix it. > - Eero > > // Tapani _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
