Re: Xsp pixel-doubling solutions for Nokia 770?
--- The ever-informative Daniel Stone [EMAIL PROTECTED] wrote: The second, and most important, is portability. Not only are you tying your app to the internet tablets, but you're tying them to the _current generation_. --- You're turning a portable app (hell, the point of SDL is portability, so you can run it anywhere), into one that's dependent on the mixture of X, an OMAP display controller supported by omapfb, and an external LCD controller also supported by omapfb. Not only is this setup quite unique to the internet tablets (due to the high resolution), but it's specific to this line of internet tablets. Good words - they help illustrate why this discussion is addressing two different things. It's understandable that any work to optimise performance for existing tablets is not interesting to employees at nokia who are working on the next generation(s) of tablets. In addition, anyone writing an sdl app/game from the ground-up would do well to keep that portability in mind. Most existing SDL applications are runnable on tablets thanks precisely to SDL abstraction. The subject *is* interesting, however, to those of us porting existing* apps to the existing* devices with a fixed feature-set. We are faced with the fact that the games are written for desktop pcs with more performance than the tablets, yet many are nearly fast enough on the current tablets. For the second group (to which i belong) there are limited options to getting acceptable performance. One is to heavily revamp and optimise each game individually. Another is to look at ways in which we can improve speed across the board (Primarily for SDL). There are any number of changes we can make in future products (such as removing the LCD controller, moving to a purely X driver, using a different display setup, whatever) that will torpedo your app. You can bypass X and go straight to the framebuffer, but it might not work correctly, and that will be your problem. It's not guaranteed to be portable to future internet tablets, let alone other platforms. If the changes are applied as drop-in replacements for existing sdl libraries, then no. The tablet version of the SDL app would use the same SDL calls, perhaps with minor changes. Future tablet SDL versions would not use those hacks. This idea is _not_ hot-air. The gp2x community has done exactly that - just one example: http://wiki.gp2x.org/wiki/Paeryn's_SDL - a community-developed hardware accelerated version of the SDL library for the GP2X Regarding your portability argument: As things stand today, we already *do* need to make non-portable changes to get acceptable performance using the existing ITOS. The best example of this is the fact that to use pixel-doubling, games using SDL_Flip and partial screen UpdateRect must be modified to not use SDL_Flip, and update the full 320x240 or 400x240 screen, every frame. as adequately demonstrated by http://pupnik.de/aliens-1.0.2_Nokia.tgz I think it bears repeating that this discussion is woefully conflating two seperate topics, and much of this debate is unnecessary if we keep the seperateness of the two goals in mind, namely: A) Improving game performance on existing tablets, and B) Improving game performance on future tablets. So lets do that. Let's let the gurus at Nokia work on the next great thing, and us plebes in the community work on getting acceptable SDL/game performance for the current tablets. Cheers 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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Arnim Sauerbier wrote: Regarding your portability argument: As things stand today, we already *do* need to make non-portable changes to get acceptable performance using the existing ITOS. The best example of this is the fact that to use pixel-doubling, games using SDL_Flip and partial screen UpdateRect must be modified to not use SDL_Flip, and update the full 320x240 or 400x240 screen, every frame. as adequately demonstrated by http://pupnik.de/aliens-1.0.2_Nokia.tgz I think it bears repeating that this discussion is woefully conflating two seperate topics, and much of this debate is unnecessary if we keep the seperateness of the two goals in mind, namely: A) Improving game performance on existing tablets, and B) Improving game performance on future tablets. There's also overlap: C) Do the improvements in the way that allows using the N800 software on N770 (maybe with recompile) and vice verse. And the question on which level the improvements are done. If pixeldoubled RandR gets into N800 Xserver, somebody could port it back to N770. How this and the proposed N770 hack are used through the SDL might not be same, so it makes sense to discuss both. So lets do that. Let's let the gurus at Nokia work on the next great thing, and us plebes in the community work on getting acceptable SDL/game performance for the current tablets. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Siarhei Siamashka wrote: AFAIK Xserver requests waits DSP to stop updating the framebuffer before proceeding. This works with HW, but you cannot expect it to work reliably with misc X clients as there are no guarantees about what they do. If client is not processing X events, the response would be waited forever and device freezes. If X server has some timeout for the client reply, then the server and client can be updating the framebuffer at the same time and that was what we wanted to avoid in the first place. Timeout is a perfectly valid solution in my opinion. It just requires that xserver and some thin wrapper library used by misc clients (SDL) both interact correctly. Interface of this wrapper library should be designed in such a way, that it is safe and hard to be misused (special timeout code which automatically terminates the process which refuses to give framebuffer back to xserver). I may provide some extra details about my vision of implementation details if anybody is interested. I guess it can't be helped and I will make an example application for using framebuffer directly and some kind of tutorial. Don't know when I will have enough free time to do this though. I'm pretty much confident that direct framebuffer access (also with pixel doubling support) is quite possible for SDL. I don't care much if you believe me or not :) Someone just needs to do the dirty work and implement all this stuff. Yes, it just cannot be done safely / reliably. I can't be completely sure, but I think it is possible to do safely/reliably. At least it is worth trying in my opinion. The difference in our views is that you see xserver as the only valid Nokia 770 citizen and everything else looks like a very ugly hack to you. I meant reliable from the normal users's point of view. What you propose can potentially have the device screen in state that requires user to reboot the device. That's why pixel doubling is not officially supported on 770. I see the problem from the completely different perspective. For many games xserver is irrelevant, they use SDL API and that is what they care about (xserver is just an additional extra layer). Game developers would like to have a fast and reliable SDL implementation which could make efficient use of all the hardware features that can benefit games. If xserver can provide all of this with some standard or nonstandard extensions, that's fine. We only need to estimate the amount of development resources and time needed to do these modifications to xserver and SDL to make use of these features. As games are not a primary target for Internet Tablets, I doubt that anything like this will be officially done any time soon (at least before the Nokia 770 end of life). Am I wrong? In this case tweaking SDL to use framebuffer directly may have a much lower cost. Especially considering that you have already solved this framebuffer sharing problem for DSP video playback. I did not suggest anything completely new ;) If there's something done for this on 770, it needs to come from the community. And I have no idea about whether it could even then end up in some possible future 770 hacker's edition. It is not quite related, but games also need a reliable and low latency method to play sounds. Current esd daemon solution is not very good for games. Maybe modifying SDL to deal with dsp tasks directly can provide some improvement. Also it would be very nice if SDL_Mixer could use dsp codecs transparently without any extra hacks to play mp3 music. I think there are some limitation from how many sources current DSP code can mix sound data and current code supports only current sound sources. If background music is needed, I'd recommend mikmod (i.e. using *.mod files for it). SDL has support for that, but I'm not sure whether that is built into 770 SDL version. Alternative is to use the media-server D-BUS API for playing music. (AFAIK it's not suitable for playing sound effects due to latency) But for hackers it's enough that it works when it works I guess. :-) I'm not sure if I can consider myself a hacker :) Something that just works is perfectly enough for a prototype. But a production system needs a reliable solution, hence I'm trying to start discussing the implementation details. SDL optimization for Nokia 770 might be an interesting task for some student with lots of free time. In any case, trying alternative solutions is a good thing, it drives the progress, allows us to improve our skills and gain experience. We get the best solution (whatever it would be) and everyone benefits as a result :) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, May 03, 2007 at 11:23:55AM -0700, ext Carl Worth wrote: On Thu, 3 May 2007 18:08:36 +0100, Matthew Allum wrote: On 5/3/07, Carl Worth [EMAIL PROTECTED] wrote: But isn't this exactly one of the features provided by the new RandR 1.2 stuff? Can it - any more details ? Would seem a really nice fit if so. Here's a link to the latest protocol specification [*]: http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;a=blob_plain;h=HEAD:randrproto.txt Here's a short excerpt that talks about the new CRTC notion in 1.2 that's independent and configured separately from the screen: [spec snipped] So to me that seems plenty flexible to do what's needed. The X server could advertise two CRTCs: one covering the entire screen, and one covering only half with pixel-doubling, and client-initiated events could control which CRTC is connected to the output (obviously only one in this device) at any given time. Daniel, am I on the right track with this? Yep, you are. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Sun, May 06, 2007 at 04:57:58PM +0300, ext Siarhei Siamashka wrote: On Thursday 03 May 2007 12:58, Eero Tamminen wrote: Yes, it just cannot be done safely / reliably. I can't be completely sure, but I think it is possible to do safely/reliably. At least it is worth trying in my opinion. The difference in our views is that you see xserver as the only valid Nokia 770 citizen and everything else looks like a very ugly hack to you. I see the problem from the completely different perspective. For many games xserver is irrelevant, they use SDL API and that is what they care about (xserver is just an additional extra layer). Game developers would like to have a fast and reliable SDL implementation which could make efficient use of all the hardware features that can benefit games. If xserver can provide all of this with some standard or nonstandard extensions, that's fine. We only need to estimate the amount of development resources and time needed to do these modifications to xserver and SDL to make use of these features. As games are not a primary target for Internet Tablets, I doubt that anything like this will be officially done any time soon (at least before the Nokia 770 end of life). Am I wrong? In this case tweaking SDL to use framebuffer directly may have a much lower cost. Especially considering that you have already solved this framebuffer sharing problem for DSP video playback. I did not suggest anything completely new ;) Hi, This is sort of my blanket reply to all the mails on the issue. There are two main issues here, of which the first is design. It's simple: we picked one window system, which happened to be X. We could've written our window system that simply performed arbitration for fb access, but we didn't, and for a pretty good reason. We chose X as a good abstract windowing system that solved all our problems. The framebuffer was an implementation detail, primarily based on the expertise available to us. The second, and most important, is portability. Not only are you tying your app to the internet tablets, but you're tying them to the _current generation_. We don't guarantee any APIs below X. If you want to hit the framebuffer, that's your choice, but I'm not going to guarantee that X won't be fiddling the framebuffer underneath you. It's not designed to play nice with other apps sharing the same framebuffer, and it won't be. Future releases of X may stomp the framebuffer more often. They may use acceleration, which you'll miss out on. They may not use the framebuffer at all, which will leave you high and dry. You're turning a portable app (hell, the point of SDL is portability, so you can run it anywhere), into one that's dependent on the mixture of X, an OMAP display controller supported by omapfb, and an external LCD controller also supported by omapfb. Not only is this setup quite unique to the internet tablets (due to the high resolution), but it's specific to this line of internet tablets. There are any number of changes we can make in future products (such as removing the LCD controller, moving to a purely X driver, using a different display setup, whatever) that will torpedo your app. I appreciate your zeal for faster-running games. There are certainly ways you can make it faster, but everything has an associated cost. You can bypass X and go straight to the framebuffer, but it might not work correctly, and that will be your problem. It's not guaranteed to be portable to future internet tablets, let alone other platforms. It won't even necessarily interoperate with things like dialog boxes and info popups. In short, you can do what you like, but you get to keep both pieces. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
If new Xomap doesn't work on the 770, I'd like to know about it. (I don't have time to constantly test it, but I can -- and will -- fix it.) I have found what triggers the Xsp disabling from SDL for IT 2005, 2006, and 2007 hacker ed. Doubling gets disabled whenever we update less than the full 320x240 screen. this breaks: SDL_UpdateRect (SDL_Video, updated.x, updated.y, updated.w, updated.h); this works: SDL_UpdateRect (SDL_Video, 0, 0, 320, 240); The same problem occurs in other SDL programs that do not update a full 320x240 screen each frame. I have prepared a simple SDL demo that illustrates this. It should be easier to understand and modify than the Ur-Quan Masters sources. Grab it here: http://pupnik.de/aliens-1.0.2_Nokia.tgz This contains a binary tgz for testing, as well as the source. Untar to home directory and use F6 button (top left on device) to toggle xsp doubling. To verify that updates outside of the doubled window are not affecting the doubling, change #define VIDWIN_X800 to #define VIDWIN_X640 and disable my onscreen buttons by commenting out these lines SDL_BlitSurface(buttonsurface,buttsrc,screen,buttdest); SDL_UpdateRect(screen, 0, 0, 0, 0); I would appreciate anyone interested in SDL and pixel doubling taking time to look it over. This is about as simple a 'real world' test case as you're going to get. Arnim Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thursday 03 May 2007 12:58, Eero Tamminen wrote: ext Siarhei Siamashka wrote: What problem with using framebuffer directly? Everything should be fine, you can get notifications from xserver when your window becomes obscured, so you can stop drawing. I suggest you to try MPlayer on Nokia 770 to check how it interacts with xserver. The worst thing that can happen is some garbage data left on screen on fast applications switching. That can happen because there is no support to synchronize access to framebuffer in a reliable way (application using framebuffer directly may get notification from the xserver about getting inactive too late and overwrite some other application window). Adding support to xserver for proper synchronization with direct framebuffer access applications should be quite possible. It already synchronizes access to framebuffer with DSP (Xsp API for registering DSP area). Almost all the necessary changes will probably have to be added at the same places in xserver which support interaction with DSP. AFAIK Xserver requests waits DSP to stop updating the framebuffer before proceeding. This works with HW, but you cannot expect it to work reliably with misc X clients as there are no guarantees about what they do. If client is not processing X events, the response would be waited forever and device freezes. If X server has some timeout for the client reply, then the server and client can be updating the framebuffer at the same time and that was what we wanted to avoid in the first place. Timeout is a perfectly valid solution in my opinion. It just requires that xserver and some thin wrapper library used by misc clients (SDL) both interact correctly. Interface of this wrapper library should be designed in such a way, that it is safe and hard to be misused (special timeout code which automatically terminates the process which refuses to give framebuffer back to xserver). I may provide some extra details about my vision of implementation details if anybody is interested. I guess it can't be helped and I will make an example application for using framebuffer directly and some kind of tutorial. Don't know when I will have enough free time to do this though. I'm pretty much confident that direct framebuffer access (also with pixel doubling support) is quite possible for SDL. I don't care much if you believe me or not :) Someone just needs to do the dirty work and implement all this stuff. Yes, it just cannot be done safely / reliably. I can't be completely sure, but I think it is possible to do safely/reliably. At least it is worth trying in my opinion. The difference in our views is that you see xserver as the only valid Nokia 770 citizen and everything else looks like a very ugly hack to you. I see the problem from the completely different perspective. For many games xserver is irrelevant, they use SDL API and that is what they care about (xserver is just an additional extra layer). Game developers would like to have a fast and reliable SDL implementation which could make efficient use of all the hardware features that can benefit games. If xserver can provide all of this with some standard or nonstandard extensions, that's fine. We only need to estimate the amount of development resources and time needed to do these modifications to xserver and SDL to make use of these features. As games are not a primary target for Internet Tablets, I doubt that anything like this will be officially done any time soon (at least before the Nokia 770 end of life). Am I wrong? In this case tweaking SDL to use framebuffer directly may have a much lower cost. Especially considering that you have already solved this framebuffer sharing problem for DSP video playback. I did not suggest anything completely new ;) It is not quite related, but games also need a reliable and low latency method to play sounds. Current esd daemon solution is not very good for games. Maybe modifying SDL to deal with dsp tasks directly can provide some improvement. Also it would be very nice if SDL_Mixer could use dsp codecs transparently without any extra hacks to play mp3 music. But for hackers it's enough that it works when it works I guess. :-) I'm not sure if I can consider myself a hacker :) Something that just works is perfectly enough for a prototype. But a production system needs a reliable solution, hence I'm trying to start discussing the implementation details. SDL optimization for Nokia 770 might be an interesting task for some student with lots of free time. In any case, trying alternative solutions is a good thing, it drives the progress, allows us to improve our skills and gain experience. We get the best solution (whatever it would be) and everyone benefits as a result :) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Matthew Allum 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. I guess that means SDL cant run on a raw framebuffer. It can. The problem is that it's not the only process running. Think what would / should happen if user presses power menu while game has switched to another VT... I think Daniel has also mentioned some (kernel) race conditions in switching VT. I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, Eero Tamminen wrote: Hi, ext Matthew Allum wrote: ...clip... I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. just my two cents... -Markku- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Markku Vire wrote: ...clip... I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: I guess that means SDL cant run on a raw framebuffer. It can. The problem is that it's not the only process running. Think what would / should happen if user presses power menu while game has switched to another VT... It would switch back to X VT ? Isnt that what you want ? i.e systemUI or whatever could manage this. I think Daniel has also mentioned some (kernel) race conditions in switching VT. Doh! I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Markku Vire [EMAIL PROTECTED] wrote: If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. If the games need everything an xserver provides then this could be another option (if a little more extreme =)) -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
--- Daniel Stone [EMAIL PROTECTED] wrote: I assume your 'xrandr' screenshot is taken on the desktop? RandR doesn't imply a specific scaling algorithm. Yes. I mistakenly assumed that xrandr would imply a point-scaler algorithm. I don't see the conflict between working on new Xomap versions and improving the N800. There is none, but look again at the title of this thread. :) I don't see the point in doing pixel doubling in software. The point is to consider alternatives to improve performance for SDL games on the 770 (and by extension, the 800). It's not about memcpy. I think the _maximum theoretical_ rate of screen updates is 28 fps due to the limited bandwidth between OMAP dispc and Hailstorm. You cannot push pixels any faster than this, even if you try, and even if you optimise SDL to death. Thanks for that info. I estimate my action games need roughly 20-25 FPS at 640x480 and RPGs 8-15 FPS at 800x480, so available bandwidth would be sufficient, correct? I'd like to thank Matthew, Eero, Daniel and Tapani for sharing their ideas on the future of pixel doubling and Xomap here, but given the status of N770 support, we in the community can not reasonably ask or expect Nokia to implement them for IT2006. If this is correct, I respectfully request that discussion about future Xomap releases be forked to another thread and we return here to the question of how to improve SDL game performance on the current OS. To review: - When UQM updates the full 320x240 screen (as in the intro and settings menus) Xsp doubling works as intended. When it updates portions of the screen (main menu, combat, dialogues) doubling is getting disabled. I don't understand why this is happening and apparently nobody else does either. - UQM combat is running at 21-24 FPS in 320x240 mode and at 6-11 FPS in 640x480. Getting 640x480 up to 20+ FPS is all that's needed to make it playable. - Given the stated goal (deliver SDL games to current tablet users) and the known constraints (Xsp problems, no Xomap fixes for IT2006), I see three potential solutions for the community (not Nokia): 1) find out and document how to avoid the Xsp-doubling/damage problems for SDL apps, in general 2) write a SDL putrect equivalent that can use DSP pixel doubling directly, without using Xsp 3) write a fast SDL putrect equivalent direct to framebuffer (cf mplayer) - optional SW scaling There are a number of classic SDL games that are close to playable on the 770. We could dive into each one individually and look for performance gains, but speeding-up scaled SDL surfaces across the board would yield a bigger payoff. I have doubts whether #1 is possible and #2 would require an intrepid coder who can venture into 'here be dragons' DSP-land. I think #3 (basically Siarhei's suggestion) looks like the most general and do-able route to speed up SDL games, since he's already implemented something like this for mplayer. Any thoughts? (besides sell your 6-month old 770) 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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Eero Tamminen wrote: ext Markku Vire wrote: If we need one fullscreen app, why not to launch a new X-session that uses this lower, pixel-doubled resolution and then run our SDL game there? Other applications would not recognize anything. Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. So to sum it up - for this to be workable solution, not hack with various nasty side effects it should: 1. not crash due to pixeldoubling mode left turned on by mistake 2. allow system dialogs and infoprints to overlay active window and have normal density (i.e. 800x480) 3. allow SDL apps to use half resolution(s) easily 4. optionally allow to intermix updates both resolutions at it suits developer (not portable, maemo specific port) 4. needs to work anyway due to 2. and also 3. can be written by using 4. Still this leads me to original suggestion of having pixel doubling to be not persinsten flag but property of rectangle update. If this is not possible to do in X the most sane solution IMO is to hack direct framebuffer access it into SDL to do such updates possibly together with emulating different resolutions in SDL too. Since we have sources there can be community volunteers to do it (including myself). The question is, does it have any chance to be merged to official firmware? Expecting people to update SDL just for your game is not good. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: [...] Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. What problem with using framebuffer directly? Everything should be fine, you can get notifications from xserver when your window becomes obscured, so you can stop drawing. I suggest you to try MPlayer on Nokia 770 to check how it interacts with xserver. The worst thing that can happen is some garbage data left on screen on fast applications switching. That can happen because there is no support to synchronize access to framebuffer in a reliable way (application using framebuffer directly may get notification from the xserver about getting inactive too late and overwrite some other application window). Adding support to xserver for proper synchronization with direct framebuffer access applications should be quite possible. It already synchronizes access to framebuffer with DSP (Xsp API for registering DSP area). Almost all the necessary changes will probably have to be added at the same places in xserver which support interaction with DSP. I guess it can't be helped and I will make an example application for using framebuffer directly and some kind of tutorial. Don't know when I will have enough free time to do this though. I'm pretty much confident that direct framebuffer access (also with pixel doubling support) is quite possible for SDL. I don't care much if you believe me or not :) Someone just needs to do the dirty work and implement all this stuff. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
(I have all your other mails queued up to read again and reply to, but I'd like to reply to this one as quickly as possible.) On Thu, May 03, 2007 at 12:39:11PM +0300, ext Siarhei Siamashka wrote: On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Same problem as using framebuffer directly. How user switches to another application? How to invoke power menu properly etc. What problem with using framebuffer directly? Everything should be fine, you can get notifications from xserver when your window becomes obscured, so you can stop drawing. I suggest you to try MPlayer on Nokia 770 to check how it interacts with xserver. The worst thing that can happen is some garbage data left on screen on fast applications switching. That can happen because there is no support to synchronize access to framebuffer in a reliable way (application using framebuffer directly may get notification from the xserver about getting inactive too late and overwrite some other application window). Behold, the problem. Also bear in mind that the X server is perfectly within its rights to change the framebuffer setup, layout, and dimensions, and you won't have any idea. Adding support to xserver for proper synchronization with direct framebuffer access applications should be quite possible. It already synchronizes access to framebuffer with DSP (Xsp API for registering DSP area). Almost all the necessary changes will probably have to be added at the same places in xserver which support interaction with DSP. This will _never_ be added. I think you're basically microoptimising at this point. If someone can show that our primary performance bottleneck is app - server - framebuffer (and that it's not just caused by naive use of the X libraries, which is generally the case), then sure, we've got something to work with there. But I don't see that this is at all the case. All we're adding is unnecessary complications and layering violations. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, May 03, 2007 at 02:28:04AM -0700, ext Arnim Sauerbier wrote: --- Daniel Stone [EMAIL PROTECTED] wrote: I don't see the conflict between working on new Xomap versions and improving the N800. There is none, but look again at the title of this thread. :) Pretty sure the hacker edition uses the most recent X server anyway, so it should be okay? I don't see the point in doing pixel doubling in software. The point is to consider alternatives to improve performance for SDL games on the 770 (and by extension, the 800). Yes, but if you're doing it _in software_, then surely the performance impact from that would make your lower resolution kind of pointless. It's not about memcpy. I think the _maximum theoretical_ rate of screen updates is 28 fps due to the limited bandwidth between OMAP dispc and Hailstorm. You cannot push pixels any faster than this, even if you try, and even if you optimise SDL to death. Thanks for that info. I estimate my action games need roughly 20-25 FPS at 640x480 and RPGs 8-15 FPS at 800x480, so available bandwidth would be sufficient, correct? Right. You get 28fps at 800x480, assuming you have one frame queued up to push as soon as the last one has hit. I'd like to thank Matthew, Eero, Daniel and Tapani for sharing their ideas on the future of pixel doubling and Xomap here, but given the status of N770 support, we in the community can not reasonably ask or expect Nokia to implement them for IT2006. If this is correct, I respectfully request that discussion about future Xomap releases be forked to another thread and we return here to the question of how to improve SDL game performance on the current OS. If new Xomap doesn't work on the 770, I'd like to know about it. (I don't have time to constantly test it, but I can -- and will -- fix it.) To review: - When UQM updates the full 320x240 screen (as in the intro and settings menus) Xsp doubling works as intended. When it updates portions of the screen (main menu, combat, dialogues) doubling is getting disabled. I don't understand why this is happening and apparently nobody else does either. Presumably this is because it's writing outside the 400x240 area. If you do this on older versions, pixel doubling will get disabled. If you do it using a recent (2007.whatever) version of ITOS2007, you'll just get clipped. - Given the stated goal (deliver SDL games to current tablet users) and the known constraints (Xsp problems, no Xomap fixes for IT2006), I see three potential solutions for the community (not Nokia): 1) find out and document how to avoid the Xsp-doubling/damage problems for SDL apps, in general 2) write a SDL putrect equivalent that can use DSP pixel doubling directly, without using Xsp 3) write a fast SDL putrect equivalent direct to framebuffer (cf mplayer) - optional SW scaling There are a number of classic SDL games that are close to playable on the 770. We could dive into each one individually and look for performance gains, but speeding-up scaled SDL surfaces across the board would yield a bigger payoff. I have doubts whether #1 is possible and #2 would require an intrepid coder who can venture into 'here be dragons' DSP-land. I think #3 (basically Siarhei's suggestion) looks like the most general and do-able route to speed up SDL games, since he's already implemented something like this for mplayer. We don't use the DSP for pixel doubling, it gets done by the graphics hardware (Tornado/hwa742 on 770, Hailstorm/s1d13745 on N800). As I've said before, I think the framebuffer solution is a very poor idea. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Matthew Allum wrote: I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. Windows that are not visible should not be updated, so there shouldn't be any need for Xft to regenerate the font bitmaps for text output. For banners getting pixelwise smaller text would actually be better as then it's physical size would be right (just not the borders). :-) For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) I guess this would need some testing... Anybody on the list who would be willing to patch Matchbox and SDL to test this? Or just do a simple test program using XrandR when it switches to fullscreen? I think it should be possible to test how this behaves just with Xephyr. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Matthew Allum wrote: I really think using xrandr for this wont buy you much though (in fact you'll probably loose) as you really only want the single topped app to notice the display has shrunk not everything server wide (as randr is intended). That should be a problem only from the performance point of view. I t not so much a performance problem - its much more a problem you effectively want to lie all windows but one about what the display resolution actually is. Thats not what randr is for. There will be issues. The screen DPI will change for one of which applications could respond too (font rendering wise) completely outside of MB's control. Windows that are not visible should not be updated, so there shouldn't be any need for Xft to regenerate the font bitmaps for text output. For banners getting pixelwise smaller text would actually be better as then it's physical size would be right (just not the borders). :-) For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. Note, this was just one potential problem - and with any problem theres going to be somekind of workaround. Its just special casing everything to 'subvert' randr is going to need alot and therefor I dont see what you gain from using randr to do it ? And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? No idea I guess this would be toolkit dependant. (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) MB does not unmap windows unless they are minimised. It would be trivial to make it do so however. Any comments on my 'simple' non vt switching solution without randr ? It would be fairly easy to simulate in Xephyr if thats a worry btw. -- Matthew ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi, ext Matthew Allum wrote: For system dialogs (which take focus) coming on top of the fullscreen application, the screen size was supposed to be switched back to normal by the WM before it allows it on screen. If the dialog contents are rendered before the dialog is shown, this could be a problem, but doesn't that happen at expose event i.e. hopefully late enough that the screen size is back at normal? If this cannot be guaranteed, then it's better that the screen size would be changed only when the topmost window changes. Note, this was just one potential problem - and with any problem theres going to be somekind of workaround. Its just special casing everything to 'subvert' randr is going to need alot and therefor I dont see what you gain from using randr to do it ? Daniel wants to get rid of non-standard Xsp. :-) And if that's the thing you're concerned about, then switching screen orientation will be a similar problem and Matchbox should anyway be fixed to notify only visible windows of the screen geometry changes. Its not matchbox notifying the windows that the display size has changed. Will the DPI change also for applications that don't have any mapped windows on screen? No idea I guess this would be toolkit dependant. (Did Matchbox unmap the windows when the are backgrounded, or are they just not visible?) MB does not unmap windows unless they are minimised. It would be trivial to make it do so however. Any comments on my 'simple' non vt switching solution without randr ? Using Xsp? Using TN instead of MB (why?)? It would be fairly easy to simulate in Xephyr if thats a worry btw. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, 3 May 2007 15:12:43 +0100, Matthew Allum wrote: You are essentially changing the server viewport area here *not* the display size. But isn't this exactly one of the features provided by the new RandR 1.2 stuff? -Carl pgpGTUcbNAuU5.pgp Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, 3 May 2007 18:08:36 +0100, Matthew Allum wrote: On 5/3/07, Carl Worth [EMAIL PROTECTED] wrote: But isn't this exactly one of the features provided by the new RandR 1.2 stuff? Can it - any more details ? Would seem a really nice fit if so. Here's a link to the latest protocol specification [*]: http://gitweb.freedesktop.org/?p=xorg/proto/randrproto.git;a=blob_plain;h=HEAD:randrproto.txt Here's a short excerpt that talks about the new CRTC notion in 1.2 that's independent and configured separately from the screen: To extend RandR for this model, we separate out the output, CRTC and screen configuration information and permit them to be configured separately. For compatibility with the 1.1 version of the protocol, we make the 1.1 requests simultaneously affect both the screen and the (presumably sole) CRTC and output. The set of available outputs are presented with UTF-8 encoded names and may be connected to CRTCs as permitted by the underlying hardware. CRTC configuration is now done with full mode information instead of just size and refresh rate, and these modes have names. These names also use UTF-8 encoding. New modes may also be added by the user. Additional requests and events are provided for this new functionality. ┌┬──┐ ┏━━━┳───┐ ╔╗ ╔╗ ┃ 1 ┃ │ ║ A║ ║ B║ ┃ ┏━━━╋━━━┫ ║║ ║║ ┣━━━╋━━━┛ ┃ ╚╝ ╚╝ │ ┃ 2 ┃─┐ │ ┃ ┃╔═══╗ │ ┃ ┃║ ║ │ ┗━━━┫║C ║ └───┘║ ║ ┌──┐ ┏┓ ╔══╗ ║ ║ │screen│ ┃CRTC┃ ║output║ ╚═══╝ └──┘ ┗┛ ╚══╝ In this picture, the screen is covered (incompletely) by two CRTCs. CRTC1 is connected to two outputs, A and B. CRTC2 is connected to output C. Outputs A and B will present exactly the same region of the screen using the same mode line. Output C will present a different (larger) region of the screen using a different mode line. So to me that seems plenty flexible to do what's needed. The X server could advertise two CRTCs: one covering the entire screen, and one covering only half with pixel-doubling, and client-initiated events could control which CRTC is connected to the output (obviously only one in this device) at any given time. Daniel, am I on the right track with this? -Carl [*] The gitweb process is spewing out the wrong character encoding, so if you view this in a web browser, you'll need to manually change it to UTF-8 instead of ISO-8859-1 to view it properly, (View-Character Encoding-Unicode in firefox-ish browsers for example). pgp7UuYILNSET.pgp Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
Hi; On 5/2/07, Eero Tamminen [EMAIL PROTECTED] 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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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 signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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 signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
--- Siarhei Siamashka [EMAIL PROTECTED] 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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Wed, May 02, 2007 at 01:01:00PM -0700, ext Arnim Sauerbier 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). I assume your 'xrandr' screenshot is taken on the desktop? RandR doesn't imply a specific scaling algorithm. Indeed, my plan was to just expose 800x480 and 400x240, and use the exact same pixel doubling in Hailstorm to achieve the latter. 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. I don't see the conflict between working on new Xomap versions and improving the N800. 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. I don't see the point in doing pixel doubling in software. Thus, what we have is restricted to the hardware. Not only would the expansion take CPU time, but you then have to send the entire expanded screen over RFBI, which sucks. If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps would use only 12 percent of that bandwidth It's not about memcpy. I think the _maximum theoretical_ rate of screen updates is 28fps, due to the limited bandwidth between OMAP dispc and Hailstorm. You cannot push pixels any faster than this, even if you try, and even if you optimise SDL to death. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Wednesday 02 May 2007 23:01, Arnim Sauerbier wrote: If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps would use only 12 percent of that bandwidth I'm sorry, I was the source of this misleading information, I forgot that you are a Nokia 770 user and mentioned some numbers from N800. I measured the memory bandwidth as ~170-190MB/s for memcpy and ~410MB/s for memset on N800. The same numbers on Nokia 770 are ~70-100MB/s for memcpy (depending on relative source and destination buffers alignment) and ~120MB/s for memset with the standard glibc functions. These glibc functions have ARM assembly optimizations developed by Nicolas Pitre from MontaVista Software, Inc., but according to comments found inside, they were developed for XScale cpus. Such code is not so good for Nokia 770 and can be replaced with something better. Using some arm926ej-s specific optimizations, it is possible to get ~100-110MB/s for memcpy and ~270MB/s for memset on Nokia 770. More details and a link to the necessary code can be found here: https://maemo.org/bugzilla/show_bug.cgi?id=733 Maybe it is time to try getting these optimized functions integrated into glibc for use on Nokia 770? Surely they need to be tested a bit more first. But improving core system components (glibc, xserver, SDL, ..) may help to make Nokia 770 at least a bit faster and more competitive. Any comments are surely welcome. I wonder if it would be possible to get a community improved firmware for Nokia 770 created (with bootmenu included, improvements to the kernel, gstreamer ogg vorbis support out of the box, some performance optimizations and bugfixes) and become available for download somewhere? Because of proprietary parts, probably this firmware should be hosted by Nokia in the standard place where the user needs to enter serial number to download it? Of course it would be unofficial and unsupported just like the hacker's edition. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
On Thu, May 03, 2007 at 12:35:15AM +0300, ext Siarhei Siamashka wrote: Maybe it is time to try getting these optimized functions integrated into glibc for use on Nokia 770? Surely they need to be tested a bit more first. But improving core system components (glibc, xserver, SDL, ..) may help to make Nokia 770 at least a bit faster and more competitive. Any comments are surely welcome. I wonder if it would be possible to get a community improved firmware for Nokia 770 created (with bootmenu included, improvements to the kernel, gstreamer ogg vorbis support out of the box, some performance optimizations and bugfixes) and become available for download somewhere? Because of proprietary parts, probably this firmware should be hosted by Nokia in the standard place where the user needs to enter serial number to download it? Of course it would be unofficial and unsupported just like the hacker's edition. Step one would be for someone to get up and volunteer to lead this project. Step two would be for someone to put together a coherent and compelling package set that would justify a fork. Step three would be to scout around for hosting space. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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=detailaid=531group_id=164atid=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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers // Tapani ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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 signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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 signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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
Re: Xsp pixel-doubling solutions for Nokia 770?
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
Re: Xsp pixel-doubling solutions for Nokia 770?
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 signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
-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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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 signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Xsp pixel-doubling solutions for Nokia 770?
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
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=detailaid=531group_id=164atid=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@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
