Re: [maemo-developers] Problem with Home plugin
On Thu, Mar 08, 2007, Markku Vire wrote: I wonder if the Home is already using GTypePlugin interface and dynamic types to handle the types registered by the plugins. That would be the right (tm) way to handle this in the scope of GObject... In the case of register_static one can newer unload the modules. Yes that's what we do in the new hildon-desktop code (see https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-desktop/). Unfortunately it doesn't solve all the problems. Say plugin foo links against gtkhtml, then the types for gtkhtml get registered statically, then registered again when the applet is reloaded. -- Johan Bilien [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
Hi, ext Kalle Vahlman wrote: I haven't confirmed this, but according to the (non-exhaustive) benchmarking currently it probably should be faster to work with image surface in Cairo and only push the result to X, since it is accelerated in neither. It might not be faster[1], but at least rest of the system (using X server) remains more responsive while a single client uses CPU instead of server used by all the applications being busy. This is of course assuming that Cairo's software implementation is faster to do it, which I don't know. What I *do* know is that Cairo's image backend gets a nice boost from using VFP so at least in that case it should beat Xlib surface hands down (which didn't benefit from VFP that much). - Eero [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [Fwd: [Fwd: Re: Coming back to Glade]]
Eero Tamminen wrote: Hi, Added CC to the developers list as I think this belongs there too. ext Marius Gedminas wrote: On Wed, Mar 07, 2007 at 05:55:58PM +0100, Claudio Scordino wrote: Never generate code with glade. NEVER. It's evil. glade-2 developers recommend to use only .glade files and load them using libglade. Glade-3 doesn't support at all generating code. Oh, now I see! Can I have more information about why glade-2 messed up generating code files ? Wasn't the problem fixable at all ? It is a generic problem when you use some UI tool/wizard to generate source code, and then modify the source code. If you later want to tweak something, you have to do it in the code (inconvenient), or if you use the same tool to regenerate code, you'll have to redo all your modifications (painful). Hi, Is not possible to make glade-2 generate a .c file which then is _linked_ to my C code without any modification ? This way, the .c generated by Glade would never be modified... I think that, in principle, an approach of this kind should be possible... Otherwise, using Glade-2 or Gazpacho is roughly the same, although Gazpacho does not provide any manual or guide yet... This is a problem, since we are going to sponsor Gazpacho for GTK-based applications development, and people who will receive our products won't have any idea about how using it! That's one of the reasons why we started talking about using Glade instead of Gazpacho... There are many RAD tools which handle the round-trip (some less well than the others). AFAIK with Glade the issue was that it just doesn't belong into Glade, it should be done by other, specialized programs. For example each language which has separate Gtk/Glade bindings (C, C++ etc) could have it's own code generator tool. Anyway, for interpreted languages like Python, Ruby, PHP, Perl etc. loading the Glade file with libglade is probably faster than the generated code that would be interpreted. And on Desktop reading the .glade files directly is fast enough in itself I think, the problem is just embedded devices. Unfortunately, interpreted languages don't fit our needs, because most of existing commercial applications are written in C or C++ and the porting cannot require changing the programming language... Moreover, we often have to deal with specialized devices, so probably interpreted languages wouldn't fit at all. Regards, Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [Fwd: [Fwd: Re: Coming back to Glade]]
Hi, ext Claudio Scordino wrote: Is not possible to make glade-2 generate a .c file which then is _linked_ to my C code without any modification ? This way, the .c generated by Glade would never be modified... I think that, in principle, an approach of this kind should be possible... Otherwise, using Glade-2 or Gazpacho is roughly the same, although Gazpacho does not provide any manual or guide yet... This is a problem, since we are going to sponsor Gazpacho for GTK-based applications development, and people who will receive our products won't have any idea about how using it! That's one of the reasons why we started talking about using Glade instead of Gazpacho... What's the problem in having a separate tool that generates the C-code from a glade file? It could even support all of the Glade, Gazpacho and GtkBuilder variants of glade files... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [Fwd: [Fwd: Re: Coming back to Glade]]
Eero Tamminen wrote: Hi, ext Claudio Scordino wrote: Is not possible to make glade-2 generate a .c file which then is _linked_ to my C code without any modification ? This way, the .c generated by Glade would never be modified... I think that, in principle, an approach of this kind should be possible... Otherwise, using Glade-2 or Gazpacho is roughly the same, although Gazpacho does not provide any manual or guide yet... This is a problem, since we are going to sponsor Gazpacho for GTK-based applications development, and people who will receive our products won't have any idea about how using it! That's one of the reasons why we started talking about using Glade instead of Gazpacho... What's the problem in having a separate tool that generates the C-code from a glade file? It could even support all of the Glade, Gazpacho and GtkBuilder variants of glade files... Right, probably having a separate tool for each supported programming language is better... BTW, does already exist any separate tool for C/C++ code ? Many thanks, Claudio ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
text of progress bars and comboboxes
Dear Developers, I cannot solve this 2 things in my GTK/Hildon GUI: The text in the progress bars appears alligned to the upper-left corner. (Not in the centre like in pure GTK, or in gazpacho+hildon) For example with this code: GtkWidget *progressbar1; progressbar1 = gtk_progress_bar_new (); gtk_widget_show (progressbar1); gtk_box_pack_start (GTK_BOX (vbox1), progressbar1, TRUE, FALSE, 1); gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (progressbar1), 0.5); gtk_progress_bar_set_text(GTK_PROGRESS_BAR (progressbar1),nyamm); The frame around the combobox is only at the left, rigth, upper border, but there is no line at the buttom border. With this code: GtkWidget *combobox1; combobox1 = GTK_WIDGET(gtk_combo_box_new_text()); gtk_widget_show (combobox1); gtk_box_pack_start (GTK_BOX (vbox1), combobox1, TRUE, FALSE, 0); gtk_combo_box_append_text (GTK_COMBO_BOX (combobox1), SYNC_TO_LOCAL); gtk_combo_box_append_text (GTK_COMBO_BOX (combobox1), SYNC_TO_REMOTE); gtk_combo_box_set_active( GTK_COMBO_BOX (combobox1), 0); There are no errors outside scratchbox (full GTK), but in scratchbox, or in the tablet (hildon) this 2 problems appears. Any idea? Best Regards: Denes - TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV.___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: text of progress bars and comboboxes
Hi, On 3/8/07, Denes Matetelki [EMAIL PROTECTED] wrote: Dear Developers, I cannot solve this 2 things in my GTK/Hildon GUI: The text in the progress bars appears alligned to the upper-left corner. (Not in the centre like in pure GTK, or in gazpacho+hildon) For example with this code: GtkWidget *progressbar1; progressbar1 = gtk_progress_bar_new (); gtk_widget_show (progressbar1); gtk_box_pack_start (GTK_BOX (vbox1), progressbar1, TRUE, FALSE, 1); gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (progressbar1), 0.5); gtk_progress_bar_set_text(GTK_PROGRESS_BAR (progressbar1),nyamm); The text-xalign property for GtkProgressBar is 0.0 by default in maemo gtk+. To get the text centered again you need to do something like: g_object_set (progress_bar, text-xalign, 0.5, NULL); The frame around the combobox is only at the left, rigth, upper border, but there is no line at the buttom border. With this code: GtkWidget *combobox1; combobox1 = GTK_WIDGET(gtk_combo_box_new_text()); gtk_widget_show (combobox1); gtk_box_pack_start (GTK_BOX (vbox1), combobox1, TRUE, FALSE, 0); gtk_combo_box_append_text (GTK_COMBO_BOX (combobox1), SYNC_TO_LOCAL); gtk_combo_box_append_text (GTK_COMBO_BOX (combobox1), SYNC_TO_REMOTE); gtk_combo_box_set_active( GTK_COMBO_BOX (combobox1), 0); Hum, I'm not sure what is your problem here. Which version of the software are you running? Theme? Could you provide a screenshot? Thanks, xan There are no errors outside scratchbox (full GTK), but in scratchbox, or in the tablet (hildon) this 2 problems appears. Any idea? Best Regards: Denes TV dinner still cooling? Check out Tonight's Picks on Yahoo! TV. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Serial through Bluetooth on N800
Aaron, you might want to check out the code for maemo-mapper or gpsd. As far as I know bluetooth GPS use the bluetooth serial port profile for transmitting data. Should be straightforward to extract what you need. Larry On 3/7/07, Aaron Westerdale [EMAIL PROTECTED] wrote: Hi sorry I'm new to writing apps on the N800 but want to write a program to interact with an embeded system I'm going to hook a bluetooth device to that, which is supposed to look like a serial port to the N800. So is there an application like serial port terminal or GTKterm which I use on my laptop since that would do for now. Also is there documentation on how to write a program that would use the serial port. I know I've seen that OBD-II sensor that uses a bluetooth to serial adapter to communicate to the N800 and it says right on nokia's product page that it can communicate via bluetooth to a serial port. I did download the code for the katix programs, I think Kate said that she is using the USB port like it is a serial port in there if I understood her correctly, and I've started to look through there to see if I can find anything useful in my situation also that code was written to work on the 770 so I don't know if it will be the same for the N800. Thank you for any help. -- -- Aaron Westerdaleseri ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On 3/7/07, Eero Tamminen [EMAIL PROTECTED] wrote: Err. Translucency means compositing and keeping the composited items in memory. Due to additional memory accesses needed for this, it would be slower (and take more memory) regardless of how accelerated it would be. Keeping the composited items in memory is not necessary. After you composite, you can (and often) just keep the final result around. It is true that certain applications may cache the intermediate surfaces to optimize performance, but that's where the hardware acceleration comes in. If we had it, we might not need to keep those intermediate surfaces around as much, and thus you would actually use _less_ memory if you had hardware acceleration. So, I don't buy that translucency implies increased memory use to the point that the additional performance from hardware accelerated graphics is overshadowed. You can see this even on Desktop, just ask how many gamers are happy with integrated graphics cards which share memory with the rest of the system instead of having (hundreds of megs) of their own memory in which to store textures etc. and in where the operations can be done without loading the memory bus of the rest of the system (downside is that all this costs, adds to the computer power consumption heating). :-) I don't totally agree here either. It sounds like you're saying that the hardware acceleration won't get you much unless you have dedicated video memory. Here's a counter-example: the macbook uses an integrated graphics card to do all of its fancy accelerated UI effects, including translucency. Yes, the macbook is not a gaming machine, but that's not the issue, here. The issue is that hardware-accelerated graphics enable advanced user interfaces, even w/out dedicated video memory. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On 3/8/07, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Kalle Vahlman wrote: I haven't confirmed this, but according to the (non-exhaustive) benchmarking currently it probably should be faster to work with image surface in Cairo and only push the result to X, since it is accelerated in neither. It might not be faster[1], but at least rest of the system (using X server) remains more responsive while a single client uses CPU instead of server used by all the applications being busy. This is interesting. I hadn't thought about keeping heavy calculations up at the client level in order to keep the X server responsive. Even though it goes against the whole point of the X Render architecture, it does make sense for a single-threaded X server. Have to think about that some more... [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... Although the compositing code could still be better optimized for 16-bit displays, the real bug there was that they were recompositing large surfaces at each scroll step, which will probably never be fast unless compositing is hardware accelerated. Dan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On 3/8/07, Daniel Amelang [EMAIL PROTECTED] wrote: On 3/7/07, Eero Tamminen [EMAIL PROTECTED] wrote: Err. Translucency means compositing and keeping the composited items in memory. Due to additional memory accesses needed for this, it would be slower (and take more memory) regardless of how accelerated it would be. Keeping the composited items in memory is not necessary. After you composite, you can (and often) just keep the final result around. It is true that certain applications may cache the intermediate surfaces to optimize performance, but that's where the hardware acceleration comes in. If we had it, we might not need to keep those intermediate surfaces around as much, and thus you would actually use _less_ memory if you had hardware acceleration. This doesn't make any sense. What if the surfaces are moved in relation to each other? Then the compositing has to be done again. I've never heard of a system that ignores the intermediate surfaces. I've heard of systems that let the graphics subsystem--ie hardware--take care of this, but in that case it's just shifting from system memory to graphics memory. I believe in our case, it's the same memory, so it's a wash. On 3/8/07, Daniel Amelang [EMAIL PROTECTED] wrote: On 3/7/07, Eero Tamminen [EMAIL PROTECTED] wrote: You can see this even on Desktop, just ask how many gamers are happy with integrated graphics cards which share memory with the rest of the system instead of having (hundreds of megs) of their own memory in which to store textures etc. and in where the operations can be done without loading the memory bus of the rest of the system (downside is that all this costs, adds to the computer power consumption heating). :-) I don't totally agree here either. It sounds like you're saying that the hardware acceleration won't get you much unless you have dedicated video memory. Here's a counter-example: the macbook uses an integrated graphics card to do all of its fancy accelerated UI effects, including translucency. Yes, the macbook is not a gaming machine, but that's not the issue, here. The issue is that hardware-accelerated graphics enable advanced user interfaces, even w/out dedicated video memory. Umm.. the MacBook dedicates a significant portion of system memory for integrated graphics. Where most systems that use integrated graphics allow variable amounts of memory from 8mb up and usually default to something like 32mb, the Macbook doesn't allow anything less than 80mb dedicated to graphics processing. I think that's a poor counter example. --Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, Mar 08, 2007 at 01:17:47PM -0800, ext Daniel Amelang wrote: On 3/8/07, Eero Tamminen [EMAIL PROTECTED] wrote: [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... Although the compositing code could still be better optimized for 16-bit displays, the real bug there was that they were recompositing large surfaces at each scroll step, which will probably never be fast unless compositing is hardware accelerated. Two bugs, really: a) the X server doesn't have sensible acceleration for 16-bit dest pictures. I have a preliminary patch for this which I need to get back on. b) Cairo is dumb. It could degrade to a 16-bit surface if the target is only 16, thus saving a great deal of memory and calculations. Also, last I saw, it insisted on pushing every surface as ARGB32, rather collapsing the alpha channel down to 1 bit, or removing it, if possible. a8r8g8b8 IN a8r8g8b8 OVER r5g6b5 is an incredibly expensive op ... (Note that I haven't checked this for a while.) Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, 8 Mar 2007 16:36:11 -0600,Paul Klapperich wrote: This doesn't make any sense. What if the surfaces are moved in relation to each other? Who said they are surfaces? You might have graphicsl elements that you want to draw that are represented more effciently in some vector description than in the rasterized surface, (think, a circle filled with a radial gradient which is represented with little more than a handful of numbers). But in spite of that, accelerated graphics implies more memory usage has no support at all. Accelerated graphics just implies that things get drawn faster. (Now, if that extra speed then leads to people drawing new things that then require more memory, that's a totally separate issue...) -Carl pgpAgw4zYIXQU.pgp Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, Mar 08, 2007 at 01:06:00PM -0800, ext Daniel Amelang wrote: On 3/7/07, Eero Tamminen [EMAIL PROTECTED] wrote: Err. Translucency means compositing and keeping the composited items in memory. Due to additional memory accesses needed for this, it would be slower (and take more memory) regardless of how accelerated it would be. Keeping the composited items in memory is not necessary. After you composite, you can (and often) just keep the final result around. The Composite extension to the X server requires a backing pixmap for every window, and a final pixmap which is essentially the fb. So, while you're right about compositing as a concept, I think Eero's talking abou the possibility of using the Composite extension. You can see this even on Desktop, just ask how many gamers are happy with integrated graphics cards which share memory with the rest of the system instead of having (hundreds of megs) of their own memory in which to store textures etc. and in where the operations can be done without loading the memory bus of the rest of the system (downside is that all this costs, adds to the computer power consumption heating). :-) I don't totally agree here either. It sounds like you're saying that the hardware acceleration won't get you much unless you have dedicated video memory. He is, and I'm willing to back him up. Here's a counter-example: the macbook uses an integrated graphics card to do all of its fancy accelerated UI effects, including translucency. Yes, the macbook is not a gaming machine, but that's not the issue, here. The issue is that hardware-accelerated graphics enable advanced user interfaces, even w/out dedicated video memory. It would be nice if we had the MacBook hardware in the N800's form factor, with the exact same power consumption. Tragically, this is not the case, and our memory bandwidth is, shall we say, not staggeringly high, limited both by raw clock speed, and memory bus design. The MacBook has PCIE, and fast main memory, meaning that it's able to push textures between the GPU and main memory at a blazing fast rate. N800 has its own 'video memory' for the final framebuffer (so your main memory isn't impacted by the load of scanning out), but the rest would have to be done in main memory, where you're in direct contention with applications for the bandwidth. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Fri, 9 Mar 2007 00:53:18 +0200, Daniel Stone wrote: On 3/8/07, Eero Tamminen [EMAIL PROTECTED] wrote: [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... ... b) Cairo is dumb. It could degrade to a 16-bit surface if the target is only 16, thus saving a great deal of memory and calculations. I'd still like to see a test case for the people running into slowness here. Cairo should already be creating 16-bit surfaces when possible, (for example in _cairo_xlib_surface_create_similar when given a 16-bit surface to start with). But cairo wasn't always clever about this, no. Now, ifthe application is actually handing cairo an ARGB32 image surface, then that's a totally separate issue, (and the application should just be fixed to not do that). -Carl pgpWGPBjcNh3v.pgp Description: PGP signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
On Thu, Mar 08, 2007 at 03:05:12PM -0800, ext Carl Worth wrote: On Fri, 9 Mar 2007 00:53:18 +0200, Daniel Stone wrote: On 3/8/07, Eero Tamminen [EMAIL PROTECTED] wrote: [1] There's a bug in Cairo bugzilla about slowness on 16-bit display when using Render though... ... b) Cairo is dumb. It could degrade to a 16-bit surface if the target is only 16, thus saving a great deal of memory and calculations. I'd still like to see a test case for the people running into slowness here. Cairo should already be creating 16-bit surfaces when possible, (for example in _cairo_xlib_surface_create_similar when given a 16-bit surface to start with). But cairo wasn't always clever about this, no. Ah, if it's been fixed since I last checked, that'd be awesome. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
N800 questions
Hi all, I have 2 questions to ask reguarding the n800: 1. How do I set it to start application automatically when I boot into the os? 2. How do I permanently install a module (the WLAN driver) Someone mentioned that I need to put it in the initfs folder, but it says device does not have enough space. I really appreciate all the help I have gotten on this mailing list Thanks Michael ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Serial through Bluetooth on N800
Larry Thank you, I started looking at the code for maemo-mapper and it looks very readable and I hope to find everything I need. Once I figure out how things work around the here I will create a project so others can use my code for an example or what ever others can use it for. On 3/8/07, Larry Battraw [EMAIL PROTECTED] wrote: Aaron, you might want to check out the code for maemo-mapper or gpsd. As far as I know bluetooth GPS use the bluetooth serial port profile for transmitting data. Should be straightforward to extract what you need. Larry On 3/7/07, Aaron Westerdale [EMAIL PROTECTED] wrote: Hi sorry I'm new to writing apps on the N800 but want to write a program to interact with an embeded system I'm going to hook a bluetooth device to that, which is supposed to look like a serial port to the N800. So is there an application like serial port terminal or GTKterm which I use on my laptop since that would do for now. Also is there documentation on how to write a program that would use the serial port. I know I've seen that OBD-II sensor that uses a bluetooth to serial adapter to communicate to the N800 and it says right on nokia's product page that it can communicate via bluetooth to a serial port. I did download the code for the katix programs, I think Kate said that she is using the USB port like it is a serial port in there if I understood her correctly, and I've started to look through there to see if I can find anything useful in my situation also that code was written to work on the 770 so I don't know if it will be the same for the N800. Thank you for any help. -- -- Aaron Westerdaleseri -- -- Aaron Westerdale ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Wishlist (was:Re: N800 and USB host mode)
ext Daniel Stone wrote: On Thu, Mar 08, 2007 at 01:06:00PM -0800, ext Daniel Amelang wrote: On 3/7/07, Eero Tamminen [EMAIL PROTECTED] wrote: Err. Translucency means compositing and keeping the composited items in memory. Due to additional memory accesses needed for this, it would be slower (and take more memory) regardless of how accelerated it would be. Keeping the composited items in memory is not necessary. After you composite, you can (and often) just keep the final result around. The Composite extension to the X server requires a backing pixmap for every window, and a final pixmap which is essentially the fb. So, while you're right about compositing as a concept, I think Eero's talking abou the possibility of using the Composite extension. I think on Maemo platform we might be able to optimize memory usage since only one application window is visible at time and we are not considering to have translucent application windows. I'm currently investigating if optimizations would be possible and we could have something nice done with composite engine in matchbox-window-manager. Maybe compositor could have only desktop window with it's panels and menus, topmost application window and it's dialogs, menus etc in memory at once? Performance is also problematic, currently matchbox-window-manager with composite enabled performs rather well (xcompmgr being slightly faster though) but CPU usage is much higher meaning higher power usage. So to sum this up, we are looking and investigating the usage of composite management in Maemo. You can see this even on Desktop, just ask how many gamers are happy with integrated graphics cards which share memory with the rest of the system instead of having (hundreds of megs) of their own memory in which to store textures etc. and in where the operations can be done without loading the memory bus of the rest of the system (downside is that all this costs, adds to the computer power consumption heating). :-) I don't totally agree here either. It sounds like you're saying that the hardware acceleration won't get you much unless you have dedicated video memory. He is, and I'm willing to back him up. Here's a counter-example: the macbook uses an integrated graphics card to do all of its fancy accelerated UI effects, including translucency. Yes, the macbook is not a gaming machine, but that's not the issue, here. The issue is that hardware-accelerated graphics enable advanced user interfaces, even w/out dedicated video memory. It would be nice if we had the MacBook hardware in the N800's form factor, with the exact same power consumption. Tragically, this is not the case, and our memory bandwidth is, shall we say, not staggeringly high, limited both by raw clock speed, and memory bus design. The MacBook has PCIE, and fast main memory, meaning that it's able to push textures between the GPU and main memory at a blazing fast rate. N800 has its own 'video memory' for the final framebuffer (so your main memory isn't impacted by the load of scanning out), but the rest would have to be done in main memory, where you're in direct contention with applications for the bandwidth. Cheers, Daniel -- ___ 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
