[maemo-developers] Xsp pixel-doubling solutions for Nokia 770?

[From: Tapani Pälli]

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