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.) > 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. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
