From: Dirk M. <dm...@tz...> - 2002-07-11 08:05:47
|
Hi, I think we need a new idea for the freevo menu menu. Someone already deactivated VCD and RECORD MOVIE. I would like to add SHUTDOWN and IMAGES. There is not enough space for all this, more functions will be coming some day. The first idea is to switch to a smaller font and smaller icons. The second idea is to change the layout to something different (see http://www.media-box.org/downloads/b4.jpg). But this would require some major changes in menu.py, main.py and of course the skin. And something different: as mentioned above, I would like like to integrate an image viewer (I bought a digital camera and I'm going on vacation in 5 weeks). There are two possibilities: use the freevo osd server to display the images or use an external program. osdserver: + no more software requirements + easier to integrate + easier to fit the look and feel to freevo - the photos are jpg, so we have to load, resize and save them as png on the fly I'm thinking of iiview (http://iiview.sourceforge.net/) as the external program, haven't tried it yet but I will later today. Dischi -- Disc space -- the final frontier! |
From: Alan M. <si...@ya...> - 2002-07-11 09:35:56
|
Hello, --- Dirk Meyer <dm...@tz...> wrote: > I'm thinking of iiview > (http://iiview.sourceforge.net/) as the Just a question: I took a look at iiview, and it was written primarily for X, but it does say that it can (optionally) be used in the Linux framebuffer device. My question is basically: is this project going to go more heavily towards running under X, or will running under X basically just be an option? ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your ad for free now! http://personals.yahoo.ca |
From: Krister L. <kr...@km...> - 2002-07-11 13:12:02
|
Alan Murrell wrote: > My question is basically: is this project going to go > more heavily towards running under X, or will running > under X basically just be an option? An option I hope... / Krister |
From: Krister L. <kr...@km...> - 2002-07-11 13:10:58
|
Dirk Meyer wrote: > Hi, > > I think we need a new idea for the freevo menu menu. Someone already > deactivated VCD and RECORD MOVIE. I would like to add SHUTDOWN and > IMAGES. Sounds cool. > There is not enough space for all this, more functions will be > coming some day. The first idea is to switch to a smaller font and > smaller icons. The second idea is to change the layout to something > different (see http://www.media-box.org/downloads/b4.jpg). But this > would require some major changes in menu.py, main.py and of course the > skin. In general I'd like us to try and separate form from function. In this case it would mean that the core system would provide as much high-level support as possible to the skin for doing stuff. But I think it's reasonable to have customizable menu structures, so the main menu should be created in the skin in the Skin.__init__() function. The skin can then decide how much to put on the main page, and how it should look. The 1-column vertical menu's should be a fall-back for new functions that have no specific skin support, but the skin can choose to display specific menus in whatever way it wants. For instance exactly like the media-box example you gave. This would make sense since I guess some people might only have a harddrive (no TV tuner nor cd-rom), they probably don't want the same main menu as other people. > And something different: as mentioned above, I would like like to > integrate an image viewer (I bought a digital camera and I'm going on > vacation in 5 weeks). Cool. It's already in the TODO list. Where are you going BTW? Are you going outside the beatiful city of Bremen? :-) > There are two possibilities: use the freevo osd > server to display the images or use an external program. I tried including jpeg support, but ran into some bug I couldn't fix immediately, so I did PNG instead since that was more powerful anyway. But I'll try again, it's just a matter of spending some more time on it. External apps are good for quick results, but I also like to have the OSD stuff generic so that things like that are exactly the same on all platforms. / Krister |
From: Dirk M. <dm...@tz...> - 2002-07-12 20:01:57
|
Hi, Krister Lagerstrom wrote: > Dirk Meyer wrote: >> I think we need a new idea for the freevo menu menu. Someone already >> deactivated VCD and RECORD MOVIE. I would like to add SHUTDOWN and >> IMAGES. > > Sounds cool. I added IMAGES, now the main menu is full. I will search for smaller icons so we can decrease the font size. >> And something different: as mentioned above, I would like like to >> integrate an image viewer (I bought a digital camera and I'm going on >> vacation in 5 weeks). > > Cool. It's already in the TODO list. Where are you going BTW? Are you > going outside the beatiful city of Bremen? :-) Yes! Bremen is cold (ok, today it was sunny, over 20=B0C) and it's often raining. So I will go to Greece for two weeks -- summer, sun, beach! >> There are two possibilities: use the freevo osd server to display >> the images or use an external program. > > I tried including jpeg support, but ran into some bug I couldn't fix > immediately, so I did PNG instead since that was more powerful > anyway. But I'll try again, it's just a matter of spending some more > time on it. > > External apps are good for quick results, but I also like to have the > OSD stuff generic so that things like that are exactly the same on all > platforms. I had some problems with iiview, so I included the image viewer into freevo directly. The new files are imenu.py for all the menu stuff and iview.py, the image viewer. I added a testfolder, too, but I have no images right now I will add some samples later. If you select an image it will take a while (my camera makes images with 2 MegaPixel, resizing isn't easy). When you look at the image, the next image will be resized, so that it will load much faster. You can go one movie back (LEFT or UP) and forward (RIGHT and DOWN). Limitations:=20 - The image will be resized to the osd height and weight, ok for landscape camera pictures but not for other images. - To speed up the loading, the images will be cached. To prevent the cache from exploding, the image viewer cache files will be removed everytime you change the directory. - If you watch an image and the next is resizing (this takes 3 secs on my computer with the large images) the eventhandler isn't active. So you have to look at each image at least 3 secs. TODO: - Read the extentend information on camera images (exif) and display the information by pressing the OSD button (I already added the OSD button to freevo_config.py and rc.py) - Fix the resizing to allow portait photos - I would love to have a thumbnail function in the menu, but I think this will cost to much time :-( - Icon for the main menu Have fun Dischi --=20 UNIX _is_ user friendly - it's just selective about who its friends are! |
From: Aubin P. <au...@pu...> - 2002-07-12 22:27:20
|
On Fri, Jul 12, 2002 at 10:01:47PM +0200, Dirk Meyer wrote: > I added IMAGES, now the main menu is full. I will search for smaller > icons so we can decrease the font size. I have the original icons (all 128x128) so I can scale them down or add more. What size are you looking for? > - I would love to have a thumbnail function in the menu, but I think > this will cost to much time :-( Shouldn't be too difficult: m = os.path.listfiles('mypath') x0 = config.thumbnailoriginx y0 = config.thumbnailoriginy for myfile in m: if Image.imghdr(myfile) and os.path.isfile(myfile): x0 = x0 + 128 y0 = y0 + 128 drawbitmap(thumb(myfile,128,128),x0,y0) I don't know if this code works exactly as is, but it should give you the basic idea. Aubin > - Icon for the main menu I'll make one. Aubin |
From: Dirk M. <dm...@tz...> - 2002-07-13 15:07:58
|
Aubin Paul wrote: > On Fri, Jul 12, 2002 at 10:01:47PM +0200, Dirk Meyer wrote: >> I added IMAGES, now the main menu is full. I will search for smaller >> icons so we can decrease the font size. > > I have the original icons (all 128x128) so I can scale them down or > add more. What size are you looking for? Maybe we should move to two column style. For this, the image size is ok. BTW, nice image for the image viewer :-) > >> - I would love to have a thumbnail function in the menu, but I think >> this will cost to much time :-( > > Shouldn't be too difficult: > > m = os.path.listfiles('mypath') > x0 = config.thumbnailoriginx > y0 = config.thumbnailoriginy > for myfile in m: > if Image.imghdr(myfile) and os.path.isfile(myfile): > x0 = x0 + 128 > y0 = y0 + 128 > drawbitmap(thumb(myfile,128,128),x0,y0) > > I don't know if this code works exactly as is, but it should give you > the basic idea. This will cost too much cpu time, on my computer 3 sec for each image. If you have 200 images in the directory.... But I found out that the images from the digital camera have a thumbnail in the exif header, they are fine for this. I exchanged the exif.py with another version with more functionality and fixes for some cameras. More new features: o I switched back to the python image lib instead of the osd server resize function o left and right on your remote rotate the image, use down and up for next / prev image o added example images (two shots from my balcony, one landscape, one portait for the rotate feature) o by pressing the DISPLAY button (BTW, I removed the OSD button from rc.py and freevo_config.py) the filename and (if an exif header exists) the date and time from the picture are displayed The only thing missing right now is a zoom function. Dischi -- We live in a society where pizza gets to your house before the police. |
From: Aubin P. <au...@pu...> - 2002-07-13 17:13:21
|
> Maybe we should move to two column style. For this, the image size is > ok. BTW, nice image for the image viewer :-) I'd be happy with either two columns, or an arbitrary positioning scheme (i,e specify origin coordinates, and each menu element is just an object with methods for "selected, normal and select" > This will cost too much cpu time, on my computer 3 sec for each > image. If you have 200 images in the directory.... That's likely, though, you'd only need to do it once per image, after which, the thumb would be cached. If you added new images, only those would be processed. Still, if their is exif thumbnails then that'll work. > o I switched back to the python image lib instead of the osd server > resize function Does anyone know where the speed penalty is coming from? Is the resize OSD function using some sort of resampling or just discarding pixel data? > o left and right on your remote rotate the image, use down and up for > next / prev image Cool, and a good idea. > o added example images (two shots from my balcony, one landscape, one > portait for the rotate feature) Nice shots :) > The only thing missing right now is a zoom function. I've heard that it may be possible to use Rasterman's imlib2 functions from Python; that might help with Zoom since I've found imlib2 to be blazing fast. Also, it abstracts many, many image types rather than needing to add them individually to the osd. Aubin |
From: Dirk M. <dm...@tz...> - 2002-07-13 18:38:40
|
Aubin Paul wrote: >> Maybe we should move to two column style. For this, the image size is >> ok. BTW, nice image for the image viewer :-) > > I'd be happy with either two columns, or an arbitrary positioning > scheme (i,e specify origin coordinates, and each menu element is just > an object with methods for "selected, normal and select" Sounds good, too. If I understand you correctly this would make it easier to build a menu menu with icons only (or the text below the icons) >> o I switched back to the python image lib instead of the osd server >> resize function > > Does anyone know where the speed penalty is coming from? Is the resize > OSD function using some sort of resampling or just discarding pixel > data? The speed comes from my caching. When you watch one image the next will be risized in the background. I can't do this with the osd server. >> The only thing missing right now is a zoom function. > > I've heard that it may be possible to use Rasterman's imlib2 functions > from Python; that might help with Zoom since I've found imlib2 to be > blazing fast. Also, it abstracts many, many image types rather than > needing to add them individually to the osd. I will look into it, thanks. Dischi -- Linux - Less bugs for less bucks! |
From: Dirk M. <dm...@tz...> - 2002-07-13 19:00:54
|
Dirk Meyer wrote: > Aubin Paul wrote: >> I've heard that it may be possible to use Rasterman's imlib2 functions >> from Python; that might help with Zoom since I've found imlib2 to be >> blazing fast. Also, it abstracts many, many image types rather than >> needing to add them individually to the osd. > > I will look into it, thanks. The only imlib module I found was combined with pygtk -- we don't want that dependency. But maybe we can realize this in the osd server. Krister, is it possible to remember the last image the osd loads? Then I will load the hole big image (1600x1200) with the osd server and display only a part of it. By pressing a button, the visible part of the image will be moved without the time consuming reload. Dischi -- There ought to be a better way to start the day than by getting up in the morning. |
From: Krister L. <kr...@km...> - 2002-07-13 19:45:15
|
Dirk Meyer wrote: > The only imlib module I found was combined with pygtk -- we don't want > that dependency. Nope :-) > But maybe we can realize this in the osd > server. Krister, is it possible to remember the last image the osd > loads? Then I will load the hole big image (1600x1200) with the osd > server and display only a part of it. By pressing a button, the > visible part of the image will be moved without the time consuming > reload. Yeah, I'll fix something like that. Should be done today... / Krister |
From: Aubin P. <au...@pu...> - 2002-07-15 04:36:12
|
Well, actually, we wouldn't link imlib2 into Python, but directly into the OSD as a C function. The point would be to replace the existing scaling functions in main.c with the optimized ones; still, I'm pretty happy with the resize caching functions for the time being. On Saturday, July 13, 2002, at 03:00 PM, Dirk Meyer wrote: > Dirk Meyer wrote: >> Aubin Paul wrote: >>> I've heard that it may be possible to use Rasterman's imlib2 functions >>> from Python; that might help with Zoom since I've found imlib2 to be >>> blazing fast. Also, it abstracts many, many image types rather than >>> needing to add them individually to the osd. >> >> I will look into it, thanks. > > The only imlib module I found was combined with pygtk -- we don't want > that dependency. But maybe we can realize this in the osd > server. Krister, is it possible to remember the last image the osd > loads? Then I will load the hole big image (1600x1200) with the osd > server and display only a part of it. By pressing a button, the > visible part of the image will be moved without the time consuming > reload. > > Dischi > > -- > There ought to be a better way to start the day than by getting up in > the morning. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Freevo-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freevo-devel |
From: Krister L. <kr...@km...> - 2002-07-15 06:05:39
|
Aubin Paul wrote: > Well, actually, we wouldn't link imlib2 into Python, but directly into > the OSD as a C function. The point would be to replace the existing > scaling functions in main.c with the optimized ones; still, I'm pretty > happy with the resize caching functions for the time being. Up until now I don't feel that I have spent too much time on the OSD server stuff, it has been pretty easy and fun. But it is starting to get to the point where it'd be nice to have a faster OSD to avoid sluggishness. And I'm not so sure that it'd make sense to continue to optimize the current architecture, if we can use someone else's handcoded MMX assembly functions instead. I took a quick look at imlib2, and it seems to fit our needs well, maybe with the exception that it requires X11 to compile. I'll look into better font support in osd.py first though, it is starting to become a real limitation (i.e. not knowing string widths in pixels etc). / Krister |
From: Dirk M. <dm...@tz...> - 2002-07-15 09:21:09
|
Krister Lagerstrom wrote: > I took a quick look at imlib2, and it seems to fit our needs well, > maybe with the exception that it requires X11 to compile. I don't think this is a problem. It only requires X11 to be installed, this is not a very requirement. Even the RedHat vim packages requires X11 :-) > I'll look into better font support in osd.py first though, it is > starting to become a real limitation (i.e. not knowing string widths > in pixels etc). Fine, that would be great for the menu and the images on the right side. Dischi -- Overflow on /dev/null, please empty the bit bucket. |
From: Alan M. <si...@ya...> - 2002-07-15 18:26:06
|
--- Dirk Meyer <dm...@tz...> wrote: > Even the RedHat vim packages requires X11 :-) Only because the Spec file says it does (I imagine it uses a '--with-x' argument on the configure line). You can (and I have) compile vim from source without X11 (or you can modify the Spec file to take out the X11 stuff). A thought sort of hit me this morning, with all these improvements and functionality that is being added. I haven't taken a good look at the sources in CVS just yet, but I was thinking that if it wouldn't involve a major re-write, maybe it would be a good idea to make Freevo 9or whatever it will be called) somewhat modular? For example, there would be the basic download, which gives the basic PVR functionality (watch TV, record programs, watch DVD/VCD). Then from there, one could download, perhaps, the "Image Viewer" module, or the "Music Module", etc. Features can then be added on a module-by-module basis (for example, it may be easier to add some further features to the music-playing abilities if it were a seperate module, as opposed to built into the main application...) Just an idea. Maybe one can already do this, to a degree, just by saying "YES" or "NO" to certain options on the freevo_config.py file... Actually, on the music front, a couple more ideas (forgive me if these are already in the TODO list...): 1. The ability to play randomly and/or continuously (if that feature is already there, i haven't been able to turn it on. I tried playing with the mpg123 arguments in freevo_config, but it didn't quite work right; I haven't tried it since, though) 2. Ability to create playlists. For example, I seperate my MP3's in directories, like "Oldies", "Dance", "Pop_Rock", etc., and my Freevo menu choices reflect that. However, I wouldn't mind having a playlist that played one or to songs from each directory. I would imagine a database would be needed (MySQL??) There are already some apps out there, such as <http://www.hotscripts.com> which will do this; perhaps oneof them could be integrated into Freevo? Again, just a couple ideas... ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your ad for free now! http://personals.yahoo.ca |
From: Krister L. <kr...@km...> - 2002-07-16 02:27:07
|
Alan Murrell wrote: > A thought sort of hit me this morning, with all these > improvements and functionality that is being added. I > haven't taken a good look at the sources in CVS just > yet, but I was thinking that if it wouldn't involve a > major re-write, > maybe it would be a good idea to make > Freevo [...] somewhat > modular? It's been talked about. What I'd like is an open api where it is easy to write custom plugins for special needs. > For example, there would be the basic download, which > gives the basic PVR functionality (watch TV, record > programs, watch DVD/VCD). What you're saying makes sense, it'd be nice to have it that way. But it takes a lot more time than you think to get stuff like that working, so I'd rather just add stuff to Freevo for now and work on that later. The documentation could be better written to help people doing easier installs for now. > (for example, it may be easier to add some further > features to the music-playing abilities if it were a > seperate module, as opposed to built into the main > application...) The code would be about the same, wouldn't it? And the different parts of Freevo are not that interdependent, the music playing module could be viewed as an internal module. > Just an idea. Maybe one can already do this, to a > degree, just by saying "YES" or "NO" to certain > options on the freevo_config.py file... Well, at least we're trying to be careful about adding unnecessary dependencies. > 1. The ability to play randomly and/or continuously > (if that feature is already there, i haven't been able > to turn it on. I tried playing with the mpg123 > arguments in freevo_config, but it didn't quite work > right; I haven't tried it since, though) It's in the TODO list, along with being able to edit the song queue (add/remove) while it is playing, kinda like a jukebox. The mpg123 shuffle will not work since it is only given a song at a time by Freevo. > 2. Ability to create playlists. Already supported (since 1.0)! Just create a file named <something.m3u> which contains one filename per line, and select that in the MP3 module in freevo. Then that will look like one big directory with all the files in it. If you want to help the documentation could probably use some beefing up as you can see :-) / Krister |
From: Aubin P. <au...@pu...> - 2002-07-16 02:50:27
|
> What you're saying makes sense, it'd be nice to have it that way. But > it takes a lot more time than you think to get stuff like that working, > so I'd rather just add stuff to Freevo for now and work on that later. > The documentation could be better written to help people doing easier > installs for now. What I'd like to do/see is more work on the install.py script, to do more than just checking python dependencies; we could check library dependencies pretty easily (if os.path.isfile(something.so)) and things like allowing the user to specify the paths; after all a root-install is only necessary if you're using the framebuffer, not for X11. > Well, at least we're trying to be careful about adding unnecessary > dependencies. If anything, that's what I'd worry about; but to be honest, the only dependency that even the XMLTV Python portion ads is XML libraries, which will probably be used elsewhere. The XMLTV app itself, on the other hand ;) > It's in the TODO list, along with being able to edit the song queue > (add/remove) while it is playing, kinda like a jukebox. > > The mpg123 shuffle will not work since it is only given a song at a > time by Freevo. What about just recursively going through directories, shuffling the list and writing a temporary playlist and passing that to mpg123? It's not perfect, but it would provide a proper random (i.e. don't play the same song twice) and allow skipping, as well as viewing the list. --- import random files = os.listdir(path) templist = open('/tmp/freevo-playlist.m3u','a') while files: element = random.choice(files) myList.remove(element) templist.write(element) --- Then, we add a menuitem pointing to the playlist; click it, randomize and go. Aubin |
From: Krister L. <kr...@km...> - 2002-07-16 05:35:19
|
Aubin Paul wrote: > What I'd like to do/see is more work on the install.py script, That is a more immediate concern for me too. I just committed some new files that change the installation to use a "./configure" script. That'll probably be familiar to most people, usually I just un-tar stuff and run ./configure without even checking the README or INSTALL. > we could check library > dependencies pretty easily (if os.path.isfile(something.so)) and things > like allowing the user to specify the paths; after all a root-install is > only necessary if you're using the framebuffer, not for X11. Yep, yep, yep. :-) > If anything, that's what I'd worry about; but to be honest, the only > dependency that even the XMLTV Python portion ads is XML libraries, > which will probably be used elsewhere. Well, we already require the user to install a development version of freetype2, PIL, PyXML, libpng, etc. So it's not a standalone app anymore, maybe it makes sense to suggest auto download/compile of missing packages during configure. > What about just recursively going through directories, shuffling the > list and writing a temporary playlist and passing that to mpg123? It's > not perfect, but it would provide a proper random (i.e. don't play the > same song twice) and allow skipping, as well as viewing the list. Good idea Aubin! I took your code and pasted it into mp3.py, it seems to work OK. One thing I didn't do was recurse through all directories, it just makes a playlist of all MP3's in the current dir, feel free to work on that. There should probably be some errorchecking for maximum recursion depth, etc. And the list could be re-shuffled every time it is selected. / Krister |
From: Aubin P. <au...@pu...> - 2002-07-16 06:20:22
|
> That is a more immediate concern for me too. I just committed some new > files that change the installation to use a "./configure" script. > That'll probably be familiar to most people, usually I just un-tar > stuff and run ./configure without even checking the README or INSTALL. Good idea; should we be checking library dependencies there? > Good idea Aubin! I took your code and pasted it into mp3.py, it seems > to work OK. One thing I didn't do was recurse through all directories, > it just makes a playlist of all MP3's in the current dir, feel free to > work on that. There should probably be some errorchecking for maximum > recursion depth, etc. And the list could be re-shuffled every time it > is selected. Shouldn't be too hard to do; I modified the script to use the cache dir, but it looks good. The recursion thing would be good for me, since I have a painfully anal organization of my mp3s by Artist/Album/; I believe there is a way to prevent recursion from following symlinks and such; Aubin |
From: Alan M. <si...@ya...> - 2002-07-16 06:40:51
|
--- Krister Lagerstrom <kr...@km...> wrote: > takes a lot more time than you think to get stuff > like that working, Yeah, I figured as much. Besides that fact, it's prolly even harder to do it to an existing project than to start out with a plan from the beginning of modularity :-) > Already supported (since 1.0)! Ooops, and that's prolly commented into the freevo_config.py file somewhere, isn;t it? :-) > Just create a file named <something.m3u> which > contains one filename per line, If the files reside in different directories, presumably I should give the full (absolute?) path? > and select that in the MP3 module in freevo. > If you want to help the documentation could probably > use some beefing up as you can see :-) Well, I'll definately be able to help with that. I'm doing a fresh install, going to use "Core Distro" (http://www.sf.net/projects/coredistro) as my base, and build pretty much everything from scratch with it, documenting as I go (yes, I know the Freevo project won't necessarily be interested so much in installation from beginning to finish of the whole PVR system, but I'm doing for another reason; I hope to create a "PVR Distro" that one can download, and withing an hour, have a PVR system up and more or less ready to go!) Anyway, yeah, I'll have some *very* careful documentation that I can add. Once I have it all back up and running, I can start documenting "user featurtes", so I should be able to get started on doing that by the weekend, hopefully :-) ===== -- Alan Murrell <si...@ya...> ______________________________________________________________________ Post your ad for free now! http://personals.yahoo.ca |
From: Wan T. C. <tc...@cs...> - 2002-07-16 08:33:08
|
On Tue, 16 Jul 2002, Alan Murrell wrote: > Well, I'll definately be able to help with that. I'm > doing a fresh install, going to use "Core Distro" > (http://www.sf.net/projects/coredistro) as my base, > and build pretty much everything from scratch with it, > documenting as I go (yes, I know the Freevo project > won't necessarily be interested so much in > installation from beginning to finish of the whole PVR > system, but I'm doing for another reason; I hope to > create a "PVR Distro" that one can download, and > withing an hour, have a PVR system up and more or less > ready to go!) Anyway, yeah, I'll have some *very* > careful documentation that I can add. > Hmm. That sounds like the way to go. My brief visit to the coredistro webpage didn't enlighten me as to how they manage packages. (e.g., deb, rpm, etc.) I started with RH 7.3, and stripped everything out that I didn't need. :) Partly historic -- I'm partial towards RPM-type package maintenance systems, and I'm most familiar with RH. Guess I figured that I could pickup security fixes, updates and etc a lot easier that way. But the reality is that I'd needed a lot of other stuff that's not in the base distro (incl. gcc-3.1) and it's becoming more and more of a frankenstein.... In any case, my goal is a SDL + X11 based system. I tried to do without X11 and go with framebuffer-only tools, but that was too restrictive (e.g., I can't use xine without X11). T.C. ---- Wan Tat Chee (Lecturer) School of Computer Science, Univ. Science Malaysia, 11800 Minden, Penang, Malaysia. Ofc Ph: +604 657-7888 x 3617 Internet: tc...@cs... Web: http://nrg.cs.usm.my/~tcwan GPG Key : http://nrg.cs.usm.my/~tcwan/tcw_gpg.asc F'print : FB0F CED7 85A5 ECF9 DEF0 50E8 A550 A0D2 8638 B1EB |
From: Aubin P. <au...@pu...> - 2002-07-15 16:24:40
|
> I took a quick look at imlib2, and it seems to fit our needs well, > maybe with the exception that it requires X11 to compile. > > I'll look into better font support in osd.py first though, it is > starting to become a real limitation (i.e. not knowing string widths in > pixels etc). I believe that imlib2 has some good Freetype support; Aubin |
From: Krister L. <kr...@km...> - 2002-07-15 05:53:22
|
Dirk Meyer wrote: > Krister, is it possible to remember the last image the osd > loads? Ok, this is done now, took a little more time than I expected. There is now a couple of different buffers in the OSD server which can help with the image reload times. There is a zoom function which can extract a part (or whole) of the bitmap and scale it. I've added example code to iview.py, but it needs some work before it is finished. / Krister |
From: Dirk M. <dm...@tz...> - 2002-07-15 18:51:46
|
Krister Lagerstrom wrote: > Dirk Meyer wrote: > >> Krister, is it possible to remember the last image the osd >> loads? > > Ok, this is done now, took a little more time than I expected. There > is now a couple of different buffers in the OSD server which can help > with the image reload times. > > There is a zoom function which can extract a part (or whole) of the > bitmap and scale it. I've added example code to iview.py, but it needs > some work before it is finished. Fine, but one cache isn't enough. When I look at one image the next will be loaded. Then I want to turn off the OSD and the current image will be reloaded -- not good. So I took a look in the osd server main.c and added a cache array with 10 images in each cache. This is much faster now. But one thing I don't understand. What is this bounding box you're writing about in the code. The affect is, that every image will be zoomed, this costs too much time. Let's take a look in the source: osd_zoombitmap: osd_loadbitmap (filename, (uint8 **) &pBM, &width, &height); ok, now width and height are the sizes of the current image, ok for me. /* Bounding box default values for 0 */ if (!bbw) { bbw = width; } if (!bbh) { bbh = height; } if you say so... /* Does the bitmap actually need to be zoomed? */ if (bbw || bbh || (scalefactor != 1000)) { What? bbw and bbh _must_ be true. You zoom al the time and freevo get's a little bit slower. if (bbw!=width || bbh!=height || (scalefactor != 1000)) { fixes the problem but I don't know if this is what you want. Dischi -- PCMCIA - People Can't Memorise Computer Industry Acronyms |
From: Krister L. <kr...@km...> - 2002-07-16 06:12:25
|
Dirk Meyer wrote: > So I took a look in the osd server main.c and added a cache array with > 10 images in each cache. This is much faster now. Nice job Dischi! The code looks good and it is much faster as you say. It seems to me that OSD is faster in general also, not just for the image module. We should probably keep an eye open for the OSD server memory usage, one large image can be several megs, which adds up pretty quickly. But it looks OK for now. > But one thing I don't understand. What is this bounding box you're > writing about in the code. It is the area that is to be zoomed, if any. It is used for zooming any part of the image to any size (smaller or larger). > The affect is, that every image will be > zoomed, this costs too much time. > > Let's take a look in the source: That's a bug as you point out. It wasn't meant to do any scaling for that case. I've programmed long enough to know I get stuff like this wrong sometimes, so I should've tested it better, but I didn't want to delay committing it since it seemed to work. I saw the changes you made to iview.py. I consider you to be in charge of the image module, so you'll get to decide how stuff should be in the end. Having said that, here's some ideas that you might or might not like to use: * Let the OSD display be off by default, but let the setting (on/off) remain the same when displaying a new image. If the user wants to see the filename for each image it is easier this way. * Let buttons 0-9 set the zoom level, 0 is whole pic and 9 is max zoom (whatever that is). The cursor keys can be used to move the zoom area around. Keep up the excellent work! / Krister |