Daniel Stone wrote: > On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote: > >> Eero Tamminen wrote: >> >>> And if the game doesn't disable the double pixeling properly (e.g. if it >>> crashes or freezes), user needs to reboot the device. Not very nice >>> either... >>> >> So what happened to idea mentioned here year ago to modify Xsp (or >> whatever) API so that pixel doubling is flag of each display update >> separately? I.e. every update would be not pixel doubled unless told so >> by flag with each update. This is how it works on kernel framebuffer >> level anyway. >> > > 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. > > 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. >> Daniel Stone wrote: >> >>> I don't like it as it's far too ITOS-specific (I won't be satisfied >>> until XSP no longer exists). It'll probably be replaced with RandR some >>> time in the future, even if the fixed resolution choices are only >>> 800x480 and 400x240. >>> >> Pixel doubled resolutions would be nice and would be improvement over >> current situation indeed. What we will miss with this solution is having >> some parts of screen pixel doubled and some not like nice control area >> with nice static graphics and main pixel doubled game area. >> > > 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. > Cheers, > Daniel > // Tapani _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
