Mailing List Archive: Maemo: Developers

Xsp pixel-doubling solutions for Nokia 770?

1 2 3

View All

Index | Next | Previous | View Threaded

arnims at yahoo

Apr 27, 2007, 9:40 PM

Post #1 of 54 (3909 views)
Permalink

Xsp pixel-doubling solutions for Nokia 770?

Greetings again, Dear Maemo Developers,

I am now porting several emulators and games to the Nokia 770, some of them shown here:

http://pupnik.de/software.html

Many of these are acceptably fast at 320x240 but too slow at 640x480 or 800x480. The problem is
that some SDL applications do not maintain 2x doubling but flicker to 1x scaling - example video
here:

http://pupnik.de/UQM_Xsp_SDL_Doubling_Bugs.avi

I have spent several weeks of trial and error trying to find a way around these issues by changing
various details of the SDL implementation, but have not been successful.

I have heard that Xsp doubling is fixed now and I see there is a patch for Xomap which may solve
the doubling problems on the 770.

https://garage.maemo.org/tracker/index.php?func=detail&aid=531&group_id=164&atid=683

However, I do not see that it has been applied to my most-recent IT2006 xserver-xomap 6.6.3-28
(gregale).

Do I understand that the Xsp/Xomap bugfix will not be applied to IT2006 due to Nokia dropping
support for 770?

If this is true, is it possible to compile an unofficial Xomap server for gregale/it2006 that can
be installed without requiring reflashing the OS?

If not, could someone suggest a workaround? It seems fairly straightforward to me that a
fullscreen on-top SDL window with disabled cursor should preclude the X server from registering
damage or calling redraws to any other windows.

Regards and thanks,
Arnim Sauerbier

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

tapani.palli at nokia

Apr 30, 2007, 12:10 AM

Post #2 of 54 (3788 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

ext Arnim Sauerbier wrote:
> Greetings again, Dear Maemo Developers,
>
> I am now porting several emulators and games to the Nokia 770, some of them shown here:
>
> http://pupnik.de/software.html
>
>

Ultima IV used to be one of my favourite RPG:s, very nice :)

> Many of these are acceptably fast at 320x240 but too slow at 640x480 or 800x480. The problem is
> that some SDL applications do not maintain 2x doubling but flicker to 1x scaling - example video
> here:
>
> http://pupnik.de/UQM_Xsp_SDL_Doubling_Bugs.avi
>
>

I could not watch this video, I guess I'm missing some codecs but I can
also throw a another guess, very likely the application draws over
400x240 area. With 770 there is no clipping done for you and you have to
take care to clip your drawing to 400x240 when using pixeldoubler. IIRC
this is fixed for N800 (?)

Please note that pixeldoubler is very platform specific thing and for it
to work you have to touch the code, there's no way around it. Also, it's
not very 'official' feature for gaming (at least yet) so it's not very
well supported. Hopefully we can build some safety around it in the
future as it's very useful for gaming. Even if you take care of
clipping, a system-modal dialog or infoprint popping from the UI can
destroy the current view.

> I have spent several weeks of trial and error trying to find a way around these issues by changing
> various details of the SDL implementation, but have not been successful.
>
> I have heard that Xsp doubling is fixed now and I see there is a patch for Xomap which may solve
> the doubling problems on the 770.
>
> https://garage.maemo.org/tracker/index.php?func=detail&aid=531&group_id=164&atid=683
>
> However, I do not see that it has been applied to my most-recent IT2006 xserver-xomap 6.6.3-28
> (gregale).
>
> Do I understand that the Xsp/Xomap bugfix will not be applied to IT2006 due to Nokia dropping
> support for 770?
>
> If this is true, is it possible to compile an unofficial Xomap server for gregale/it2006 that can
> be installed without requiring reflashing the OS?
>
> If not, could someone suggest a workaround? It seems fairly straightforward to me that a
> fullscreen on-top SDL window with disabled cursor should preclude the X server from registering
> damage or calling redraws to any other windows.
>
> Regards and thanks,
> Arnim Sauerbier
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> maemo-developers mailing list
> maemo-developers [at] maemo
> https://maemo.org/mailman/listinfo/maemo-developers
>
>

// Tapani

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

Apr 30, 2007, 12:19 AM

Post #3 of 54 (3787 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Mon, Apr 30, 2007 at 10:10:23AM +0300, ext Tapani P�lli wrote:
> ext Arnim Sauerbier wrote:
> > Many of these are acceptably fast at 320x240 but too slow at 640x480 or 800x480. The problem is
> > that some SDL applications do not maintain 2x doubling but flicker to 1x scaling - example video
> > here:
> >
> > http://pupnik.de/UQM_Xsp_SDL_Doubling_Bugs.avi
>
> I could not watch this video, I guess I'm missing some codecs but I can
> also throw a another guess, very likely the application draws over
> 400x240 area. With 770 there is no clipping done for you and you have to
> take care to clip your drawing to 400x240 when using pixeldoubler. IIRC
> this is fixed for N800 (?)

Yeah, it just ignores all drawing beyond 400x240 on the N800.

> Please note that pixeldoubler is very platform specific thing and for it
> to work you have to touch the code, there's no way around it. Also, it's
> not very 'official' feature for gaming (at least yet) so it's not very
> well supported. Hopefully we can build some safety around it in the
> future as it's very useful for gaming. Even if you take care of
> clipping, a system-modal dialog or infoprint popping from the UI can
> destroy the current view.

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.

Cheers,
Daniel

Attachments:

signature.asc (0.18 KB)

eero.tamminen at nokia

Apr 30, 2007, 12:21 AM

Post #4 of 54 (3790 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

Hi,

ext Tapani P�lli wrote:
> ext Arnim Sauerbier wrote:
>> Greetings again, Dear Maemo Developers,
>>
>> I am now porting several emulators and games to the Nokia 770, some of them shown here:
>>
>> http://pupnik.de/software.html
>
> Ultima IV used to be one of my favourite RPG:s, very nice :)
>
>> Many of these are acceptably fast at 320x240 but too slow at 640x480 or 800x480. The problem is
>> that some SDL applications do not maintain 2x doubling but flicker to 1x scaling - example video
>> here:
>>
>> http://pupnik.de/UQM_Xsp_SDL_Doubling_Bugs.avi
>
> I could not watch this video, I guess I'm missing some codecs but I can
> also throw a another guess, very likely the application draws over
> 400x240 area. With 770 there is no clipping done for you and you have to
> take care to clip your drawing to 400x240 when using pixeldoubler. IIRC
> this is fixed for N800 (?)
>
> Please note that pixeldoubler is very platform specific thing and for it
> to work you have to touch the code, there's no way around it. Also, it's
> not very 'official' feature for gaming (at least yet) so it's not very
> well supported. Hopefully we can build some safety around it in the
> future as it's very useful for gaming. Even if you take care of
> clipping, a system-modal dialog or infoprint popping from the UI can
> destroy the current view.

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...

- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

Apr 30, 2007, 12:24 AM

Post #5 of 54 (3782 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Mon, Apr 30, 2007 at 10:23:37AM +0300, ext Eero Tamminen wrote:
> ext Tapani P�lli wrote:
> > Please note that pixeldoubler is very platform specific thing and for it
> > to work you have to touch the code, there's no way around it. Also, it's
> > not very 'official' feature for gaming (at least yet) so it's not very
> > well supported. Hopefully we can build some safety around it in the
> > future as it's very useful for gaming. Even if you take care of
> > clipping, a system-modal dialog or infoprint popping from the UI can
> > destroy the current view.
>
> 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...

In theory, crashing should be perfectly safe on the N800.

Cheers,
Daniel

Attachments:

signature.asc (0.18 KB)

dufkaf at seznam

Apr 30, 2007, 12:34 AM

Post #6 of 54 (3766 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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.

It is bad to turn in on and off because any other display update
(infoprint) can mess it up. If we had blitting API in Xsp with pixel
doubling flag settable per update this problem would go away.

Well in fact we have this api - framebuffer ioctl but it is not very
nice solution.

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.

Frantisek
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

tapani.palli at nokia

Apr 30, 2007, 12:49 AM

Post #7 of 54 (3801 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

Daniel Stone wrote:
> On Mon, Apr 30, 2007 at 10:10:23AM +0300, ext Tapani P�lli wrote:
>
>> ext Arnim Sauerbier wrote:
>>
>>> Many of these are acceptably fast at 320x240 but too slow at 640x480 or 800x480. The problem is
>>> that some SDL applications do not maintain 2x doubling but flicker to 1x scaling - example video
>>> here:
>>>
>>> http://pupnik.de/UQM_Xsp_SDL_Doubling_Bugs.avi
>>>
>> I could not watch this video, I guess I'm missing some codecs but I can
>> also throw a another guess, very likely the application draws over
>> 400x240 area. With 770 there is no clipping done for you and you have to
>> take care to clip your drawing to 400x240 when using pixeldoubler. IIRC
>> this is fixed for N800 (?)
>>
>
> Yeah, it just ignores all drawing beyond 400x240 on the N800.
>
>
>> Please note that pixeldoubler is very platform specific thing and for it
>> to work you have to touch the code, there's no way around it. Also, it's
>> not very 'official' feature for gaming (at least yet) so it's not very
>> well supported. Hopefully we can build some safety around it in the
>> future as it's very useful for gaming. Even if you take care of
>> clipping, a system-modal dialog or infoprint popping from the UI can
>> destroy the current view.
>>
>
> 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.
>
>

Yep, RandR would be ideal place and it would work 'globally' for the
framework then.

> Cheers,
> Daniel
>

// Tapani

_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

eero.tamminen at nokia

Apr 30, 2007, 1:02 AM

Post #8 of 54 (3771 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

Hi,

ext Frantisek Dufka 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.
>
> It is bad to turn in on and off because any other display update
> (infoprint) can mess it up. If we had blitting API in Xsp with pixel
> doubling flag settable per update this problem would go away.
>
> Well in fact we have this api - framebuffer ioctl but it is not very
> nice solution.
>
> 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.

Does RandR restore the original resolution automatically when the client
requesting a specific screen size exits? If not, it's not really a
solution as then screen would still be "messed up".

Also, it would be good to support the standard resolutions like 320x200
(with black borders) so that more programs would work unmodified. Many
games/emulators want a specific resolution.

> 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

Games can already do this on 770 by setting pixel doubling on after
blitting the more detailed graphics. But as you said RandR doesn't
support that. Besides, the infoprints would still look funny. Not
as funny as with pixel doubling, but they would be too large and
as window manager positions them right aligned, they would be clipped
from the left instead of right like with Xsp. :-)

What is really needed is a flag that is window specific.

> like nice control area with nice static graphics and main pixel
> doubled game area.

I don't think it would be a great loss if the whole window would be
pixel doubled. The screen is 226 DPI. Pixel doubled it would still
113 DPI, i.e. more accurate than most (CRT) monitors. A bonus would
be that game would use less memory for its graphics (as they are
smaller) and you don't need to modify the game to support two screen
resolutions.

- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

Apr 30, 2007, 1:11 AM

Post #9 of 54 (3774 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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

Attachments:

signature.asc (0.18 KB)

tapani.palli at nokia

Apr 30, 2007, 1:16 AM

Post #10 of 54 (3777 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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 [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

Apr 30, 2007, 1:20 AM

Post #11 of 54 (3768 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Mon, Apr 30, 2007 at 11:16:32AM +0300, Tapani P�lli wrote:
> 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.
> >
> > 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.

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.

Cheers,
Daniel

Attachments:

signature.asc (0.18 KB)

dufkaf at seznam

Apr 30, 2007, 2:26 AM

Post #12 of 54 (3788 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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?

Well, what I meant is instead of having XSPSetPixelDoubling call in Xsp
we would have XSPBlitRectangle with addition flags - i.e. something
still non-standard but easier to use. If this cannot be done then it is
bad luck. If hardware has useful feature which does not fit the design,
using extension is not that bad.

> The entire concept is a hack around games not running quickly enough in
> full resolution.

Yes, if you think different lower resolutions implemented in graphics
cards are hacks around games not running quickly then yes. Why not run
everything in highest resolution and true color. That will solve all
those problems. Well, except the speed. But this is temporary until
hardware catches up :-)

> 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.

Yes limiting ourselves to doubling is bad. Why not to add custom ratio
if N800 can do that.

This all leads to request to have some more advanced gaming API. Sadly
this is probably not what internet tablets are currently designed for.
Gamers are big target group and this device is meant for entertainment
so maybe extending target audience to gamers in not that bad idea.
Gaming devices are moving online too so this is direct competition. Why
to buy internet tablet if better Sony or Nintendo device in future will
do this too plus gaming. Unfortunately gaming business has complicated
rules similar in complexity to devices with GSM radio. BTW are internet
tablets in same Nokia multimedia division as N-Gage?

Frantisek
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

Apr 30, 2007, 2:33 AM

Post #13 of 54 (3762 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Mon, Apr 30, 2007 at 11:26:29AM +0200, ext Frantisek Dufka wrote:
> 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?
>
> Well, what I meant is instead of having XSPSetPixelDoubling call in Xsp
> we would have XSPBlitRectangle with addition flags - i.e. something
> still non-standard but easier to use. If this cannot be done then it is
> bad luck. If hardware has useful feature which does not fit the design,
> using extension is not that bad.

The initial drawing requests are long-forgotten, and we'd need some
pretty extensive modification to all the internals to mark a particular
region as being doubled.

> >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.
>
> Yes limiting ourselves to doubling is bad. Why not to add custom ratio
> if N800 can do that.

We can do more or less arbitrary scaling, yes, but unfortunately with a
few limitations (either we do it on the display controller and suffer the
bandwidth hit, or do it on Hailstorm and suffer its horribly complicated
semantics for dealing with overlays).

> This all leads to request to have some more advanced gaming API. Sadly
> this is probably not what internet tablets are currently designed for.
> Gamers are big target group and this device is meant for entertainment
> so maybe extending target audience to gamers in not that bad idea.
> Gaming devices are moving online too so this is direct competition. Why
> to buy internet tablet if better Sony or Nintendo device in future will
> do this too plus gaming. Unfortunately gaming business has complicated
> rules similar in complexity to devices with GSM radio. BTW are internet
> tablets in same Nokia multimedia division as N-Gage?

I don't know which division N-Gage is in. I can't speak for the product
managers as to targeting market segments and all the other things they
like to say.

Cheers,
Daniel

Attachments:

signature.asc (0.18 KB)

kuisma.salonen at nokia

Apr 30, 2007, 3:03 AM

Post #14 of 54 (3759 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Eero Tamminen wrote:
> Hi,
>
> ext Frantisek Dufka 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.

I would double this. Even through we could switch to lower resolution,
it would still be beneficial to have option to have just some parts of
the screen pixeldoubled. One of these cases is a game which would draw
everything (except static gui parts) pixeldoubled when the scenery moves
and then draws everything in hi-res when the scenery freezes (and only
small parts of the scenery moves).

>>
>> It is bad to turn in on and off because any other display update
>> (infoprint) can mess it up. If we had blitting API in Xsp with pixel
>> doubling flag settable per update this problem would go away.
>>

<snip>

>
> Also, it would be good to support the standard resolutions like 320x200
> (with black borders) so that more programs would work unmodified. Many
> games/emulators want a specific resolution.
>

For example SDL gets smallest res which is equally as big or bigger than
requested and gives a window of requested size having black borders
around it (I am talking obviously about fullscreen behavior here).

Of course, there is some games which doesn't use SDL but plain X, but
even in this case when you request fullscreen window, you will get one
and if you draw into 0,0 you end up having your "small window" in
topleft corner. Of course there is many possibilities for clipping
problems and other things breaking up, but the point is, if you want to
write a resolution specific game, you probably want to use SDL.

>
>> 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
>
> Games can already do this on 770 by setting pixel doubling on after
> blitting the more detailed graphics. But as you said RandR doesn't
> support that. Besides, the infoprints would still look funny. Not
> as funny as with pixel doubling, but they would be too large and
> as window manager positions them right aligned, they would be clipped
> from the left instead of right like with Xsp. :-)
>
> What is really needed is a flag that is window specific.
>

In theory it could be possible that one window (or one client) thinks
that the resolution is 400*240 but it really isn't for other clients. In
fullscreen world, this is rather simple and you would get for example
hi-res infoprints on top of pixeldoubled game window. But again, I'm not
the most specialized on these things, so it might be that doing this
would be _really_ dirty.

>
>> like nice control area with nice static graphics and main pixel
>> doubled game area.
>
> I don't think it would be a great loss if the whole window would be
> pixel doubled. The screen is 226 DPI. Pixel doubled it would still
> 113 DPI, i.e. more accurate than most (CRT) monitors. A bonus would
> be that game would use less memory for its graphics (as they are
> smaller) and you don't need to modify the game to support two screen
> resolutions.

IMO this is a loss. There is many things which you could do with the
blit-specific doubling. If it is possible to have both, why to drop
another (unless we are speaking about something which might potentially
break things)?

- -- Kuisma
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGNb8KHIcMorDK+qsRAizOAJ9i6oWLrw6hjSzpRi0/nuCh3yaD9gCfZXoH
2f8CS2naOgKGmXPiD9sgLhY=
=PIKI
-----END PGP SIGNATURE-----
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

eero.tamminen at nokia

Apr 30, 2007, 4:23 AM

Post #15 of 54 (3771 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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 :-)).

>>> 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).

- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

Apr 30, 2007, 4:26 AM

Post #16 of 54 (3771 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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.

Attachments:

signature.asc (0.18 KB)

tapani.palli at nokia

Apr 30, 2007, 4:39 AM

Post #17 of 54 (3764 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

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 [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

siarhei.siamashka at gmail

May 1, 2007, 11:47 PM

Post #18 of 54 (3779 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Monday 30 April 2007 12:26, Frantisek Dufka wrote:

> Daniel Stone wrote:
> > 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.
>
> Yes limiting ourselves to doubling is bad. Why not to add custom ratio
> if N800 can do that.
>
> This all leads to request to have some more advanced gaming API. Sadly
> this is probably not what internet tablets are currently designed for.
> Gamers are big target group and this device is meant for entertainment
> so maybe extending target audience to gamers in not that bad idea.
> Gaming devices are moving online too so this is direct competition. Why
> to buy internet tablet if better Sony or Nintendo device in future will
> do this too plus gaming. Unfortunately gaming business has complicated
> rules similar in complexity to devices with GSM radio. BTW are internet
> tablets in same Nokia multimedia division as N-Gage?

Well, SDL is to some extent this advanced gaming API, its current
implementation for Nokia 770/N800 is just poor.

As for pixel doubling, a practical solution would be just to support 400x240
fullscreen resolution in SDL so that no extra hack would be required when
porting each game or emulator in particular. N800 hardware probably
makes it possible to set any resolution up to 800x480, with all this available
using standard SDL API.

Having support for both pixel doubled and normal graphics in the same game
may be useful, but it will require extra efforts when porting games, while low
resolution may already work out of the box without doing any tweaks to the
sources. Let's try the simple solution first.

The very first step would be to take Nokia 770 xserver and SDL sources and
tweak them until setting 400x240 fullscreen resolution works transparently for
any SDL applications. Anybody up to this task?

Also it would be a good idea to benchmark SDL, identify maemo or ARM
architecture related bottlenecks and try to fix them. Many older generation
games worked perfectly on hardware way slower than Nokia 770. So
Nokia 770 may be a good platform for mobile gaming if properly
optimized (though I'm not sure about realtime games because of
unsuitable controls). I could probably do these optimizations myself, but
have quite a limited amount of free time available for free software
development.
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

ant.o at libero

May 2, 2007, 6:44 AM

Post #19 of 54 (3768 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

> As for pixel doubling, a practical solution would be just to support
> 400x240 fullscreen resolution in SDL so that no extra hack would be
> required when porting each game or emulator in particular.

+1 to this, as a user. 400x240 is a truely good resolution for a display
size like that of a portable device. If some coder can do something
towards the aim of improving gfx smoothness by rendering stuff fullscreen
at 400x240, please consider the above suggestion and don't distract with
harder to achieve aims if the "simpler" has not yet been done. The fact
that the "simpler" aim is effectively a *hard* one as it seems from the
replies to the initial post, should push the other one to a very low
priority level.

Having a fast screen update in SDL games and emulators at 400x240 (I
repeat: a nice res for that screen size!) would be a breeze of fresh air
for 770 usage :)

--
Antonio
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

eero.tamminen at nokia

May 2, 2007, 9:08 AM

Post #20 of 54 (3775 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

Hi,

Daniel Stone wrote:
>>>>> 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.

Hm. I think the API on Desktop for scaling window content is OpenGL.
;-)

>>> 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.

It's evil that games change screen resolution, system changes
should be controlled by system software instead of random apps.

If it's enough that the whole screen is scaled instead of a window or
specific update, for Maemo the XRandR approach could be joined with
my earlier proposal.

I.e. if window has certain property (say geometry=320x200), the window
manager could use XRandR to switch the screen resolution when that kind
of a window is on top/focused/fullscreen(ed). When the window is not
anymore focused/top/fullscreen or is closed, the previous/default
resolution is restored. This way banners above the window wouldn't
get the resolution changed (banners don't take focus), but dialogs
(like power menu) would.

Do you see any problems (besides getting these changes to Matchbox and
SDL after adding XRandR support to Xomap)?

- Eero

<joking>
Any chance of getting this into EWMH spec?
</joking>
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

mallum at gmail

May 2, 2007, 9:52 AM

Post #21 of 54 (3769 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

Hi;

On 5/2/07, Eero Tamminen <eero.tamminen [at] nokia> wrote:
>
> It's evil that games change screen resolution, system changes
> should be controlled by system software instead of random apps.
>
> If it's enough that the whole screen is scaled instead of a window or
> specific update, for Maemo the XRandR approach could be joined with
> my earlier proposal.
>
> I.e. if window has certain property (say geometry=320x200), the window
> manager could use XRandR to switch the screen resolution when that kind
> of a window is on top/focused/fullscreen(ed). When the window is not
> anymore focused/top/fullscreen or is closed, the previous/default
> resolution is restored. This way banners above the window wouldn't
> get the resolution changed (banners don't take focus), but dialogs
> (like power menu) would.
>
> Do you see any problems (besides getting these changes to Matchbox and
> SDL after adding XRandR support to Xomap)?
>

Theres a big downside to this approach in that matchbox already
supports randr and has done for a while in order to facilitate stuff
like screen rotation - matchbox will in effect resize all windows and
position dialogs as to adapt to the new screen resolution - like other
WM's also do. This is what you'd expect in the general case.

So if you pixel double via randr every single application is going to
get resized and un resized. Whats worse is theres not going to be an
easy way around this as much stuff in matchbox is obviously dependant
on the 'real' display geometry.

For the use case which is being described here - namely always full
screen applications which need exclusive access to the display at a
lower resolution Why not do something like switch to another VT and do
it directly on the framebuffer ? and then wrap this with something
that makes sure you can always safely return to/from X - maybe
something managed through systemUI or some such. This is a different
approach but could prove simpler in the long run though I havn't
thought long and hard about it so there could be some obvious
downsides - More a random idea :)

-- Matthew
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

daniel.stone at nokia

May 2, 2007, 10:27 AM

Post #22 of 54 (3755 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Wed, May 02, 2007 at 07:08:24PM +0300, Eero Tamminen wrote:
> Hi,
>
> Daniel Stone wrote:
> > Hence, XRandR. The only thing worse than designing a bad API, is
> > designing _another_ API.
>
> Hm. I think the API on Desktop for scaling window content is OpenGL.
> ;-)

Sure, but we don't have OpenGL support right now, and the only other way
is using a Render transformation for every op, which would be
mindblowingly slow. RandR allows you to change the screen size. This
is what pixel doubling does: it changes the size of the entire screen,
really.

XRandR is a way to do this that doesn't end up making everyone angry.

> > If you can come up with a policy that works in corner cases, you're a
> > genius.
>
> It's evil that games change screen resolution, system changes
> should be controlled by system software instead of random apps.

Indeed.

> If it's enough that the whole screen is scaled instead of a window or
> specific update, for Maemo the XRandR approach could be joined with
> my earlier proposal.
>
> I.e. if window has certain property (say geometry=320x200), the window
> manager could use XRandR to switch the screen resolution when that kind
> of a window is on top/focused/fullscreen(ed). When the window is not
> anymore focused/top/fullscreen or is closed, the previous/default
> resolution is restored. This way banners above the window wouldn't
> get the resolution changed (banners don't take focus), but dialogs
> (like power menu) would.
>
> Do you see any problems (besides getting these changes to Matchbox and
> SDL after adding XRandR support to Xomap)?

It's a shocking hack, but sure, if we desperately need to support this
kind of thing, then this seems like the most fail-safe option (the
current option arguably being the most desirable, as it limits the
damage). Of course, having OpenGL support would be preferable, but
that's neither here nor there.

> <joking>
> Any chance of getting this into EWMH spec?
> </joking>

Ha! You first.

Cheers,
Daniel

Attachments:

signature.asc (0.18 KB)

daniel.stone at nokia

May 2, 2007, 10:40 AM

Post #23 of 54 (3771 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Wed, May 02, 2007 at 05:52:38PM +0100, ext Matthew Allum wrote:
> Theres a big downside to this approach in that matchbox already
> supports randr and has done for a while in order to facilitate stuff
> like screen rotation - matchbox will in effect resize all windows and
> position dialogs as to adapt to the new screen resolution - like other
> WM's also do. This is what you'd expect in the general case.
>
> So if you pixel double via randr every single application is going to
> get resized and un resized. Whats worse is theres not going to be an
> easy way around this as much stuff in matchbox is obviously dependant
> on the 'real' display geometry.

I guess you could hack around this by walking the tree and looking for a
full-screen override-redirect window (or one with the appropriate
class). If you find one, then pend the resolution change of all windows
to when you switch away from it; a correctly-behaved app will fix the
resolution before it leaves, thus leaving you with no need to bother
everything else. Would that work?

> For the use case which is being described here - namely always full
> screen applications which need exclusive access to the display at a
> lower resolution Why not do something like switch to another VT and do
> it directly on the framebuffer ? and then wrap this with something
> that makes sure you can always safely return to/from X - maybe
> something managed through systemUI or some such. This is a different
> approach but could prove simpler in the long run though I havn't
> thought long and hard about it so there could be some obvious
> downsides - More a random idea :)

Egh, my eyes! Dealing with input in particular could be a pain.

Cheers,
Daniel

Attachments:

signature.asc (0.18 KB)

siarhei.siamashka at gmail

May 2, 2007, 11:11 AM

Post #24 of 54 (3762 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

On Wednesday 02 May 2007 20:40, Daniel Stone wrote:
> > For the use case which is being described here - namely always full
> > screen applications which need exclusive access to the display at a
> > lower resolution Why not do something like switch to another VT and do
> > it directly on the framebuffer ? and then wrap this with something
> > that makes sure you can always safely return to/from X - maybe
> > something managed through systemUI or some such. This is a different
> > approach but could prove simpler in the long run though I havn't
> > thought long and hard about it so there could be some obvious
> > downsides - More a random idea :)
>
> Egh, my eyes! Dealing with input in particular could be a pain.

This is what works for MPlayer on Nokia 770. It creates x11 window just
to reserve some screen space and prevent other applications from using
it. After that, it renders data directly to framebuffer and uses x11 for
input. It is not very clean, but it works. And it works fast. The same trick
can be probably done for SDL.

Here is a link to the old discussion in the mailing list with the initial
idea: http://maemo.org/pipermail/maemo-developers/2006-December/006646.html
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

arnims at yahoo

May 2, 2007, 1:01 PM

Post #25 of 54 (3771 views)
Permalink

Re: Xsp pixel-doubling solutions for Nokia 770? [In reply to]

--- Siarhei Siamashka <siarhei.siamashka [at] gmail> wrote:

Siarhei Siamashka wrote:

> This is what works for MPlayer on Nokia 770. It creates x11 window just
> to reserve some screen space and prevent other applications from using
> it. After that, it renders data directly to framebuffer and uses x11 for
> input. It is not very clean, but it works. And it works fast. The same trick
> can be probably done for SDL.

Indeed SDL is the 'gaming api' in-use for games that run acceptably on tablets, and Xrandr would
be the natural choice for changing screen resolution. While that would be fast and simple, it
doesn't look good. See

http://pupnik.de/ScalersExult.png

As the screenshots show, a Scale2x or 2xSai scaler yields much more readable text (view on the
tablet to get a good idea of this).

While I appreciate that the folks at Nokia are looking into solutions aimed at future Xomap and
tablet releases, my interest is directed toward improvements that can apply to current N770 and
N800 tablets.

To this end, my hope would be for a fast Implementation of SDL's HWSURFACE that would allow the
SDL app to use an internal high quality scaler or 800x480 native resolutions.

Siarhei Siamashka wrote:

> Also it would be a good idea to benchmark SDL, identify maemo or ARM
> architecture related bottlenecks and try to fix them. Many older generation
> games worked perfectly on hardware way slower than Nokia 770. So
> Nokia 770 may be a good platform for mobile gaming if properly
> optimized
> ....
> This is what works for MPlayer on Nokia 770. It creates x11 window just
> to reserve some screen space and prevent other applications from using
> it. After that, it renders data directly to framebuffer and uses x11 for
> input. It is not very clean, but it works. And it works fast. The same trick
> can be probably done for SDL.

If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps would use only 12 percent
of that bandwidth

I feel that a better SDL implementation would be time/money well spent, as it would be an easier
upgrade than Xomap for current 770/800s, and would also benefit future nokia tablets.

Arnim

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://maemo.org/mailman/listinfo/maemo-developers

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads