ext Frantisek Dufka wrote: > Tapani Pälli wrote: >>> As for the manual vs automatic updates, that brings another question. >>> How often is the screen really updated? I saw in the kernel source >>> there is manual vs automatic update mode but which one is actualy >> >> We are updating areas (dirty-rects), it would hog the memorybus if we >> would be updating whole screen all the time. > > Yes, I didn't mean whole screen. As for the modes I later found dmesg > prints only changes between states 'disabled' and 'manual' so the > answer is manual. > >> Do you think >> blitting is too slow now? I don't think X is there the bottleneck at >> all, the true bottleneck is the memorybus. > > No I was not concerned about speed but more about functionality and > unneeded layers that may hide some of them. As for the functionality I > mean vblank syncing/double buffering to take care of the tearing > effect and maybe also direct YUV blits for implementing video player > in SDL. As SDL can lie about
Hmm let's see if we could come up with a nice solution with discussion. Direct access to fb would mean permission problems. But there could be another fb with different permissions (?) ... Maybe at first the tearing should be solved at driver level so that client can request the flush. > everything I'm not sure if it supports YUV surfaces in software or > uses kernel features. Also as for the pixel doubling, this was told > it is basically unstable because you cannot turn it off fast enough or > at all if X decides to draw something or your application crashes. > http://maemo.org/maemowiki/GameDevelopment#head-6d05e5cc815205f4c0ac4ba09fee0ea5c9d3ff85 > Yep this is sad but true :-/ Scaling should be handled better ... we have some plans for this. > By using kernel driver directly from SDL it might be easier as you > might set pixel doubling mode per each update rectangle separately (if > I understood kernel source correctly, which may not be the case :) Yes, this is possible and quite ideal for applications. Right now the "interface" is through Xsp extension and scaling happens then for everything (without clipping). There was some discussion also that windowmanager could handle the global enabling and disabling of scaler, but individual rects sounds very nice indeed. > so it will not remain turned on. Otherwise there is no need to use it > directly if X allows to do all of this properly. > > Frantisek > // Tapani _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
