Re: Clutter in Fremantle (Alpha SDK)
On Tue, 2009-03-17 at 18:04 +0100, ext Henrik Hedberg wrote: Kimmo Hämäläinen wrote: On Tue, 2009-03-17 at 08:37 +0100, ext Henrik Hedberg wrote: Is this somehow related to this statement: It is assumed that we will have only one OpenGL drawing context, and thus a single process running in the system will be using Clutter at a time. This process will be the window manager and the implementor of all challenging graphical UI effects on the screen. [2] This we have assumed in the design, but it does not mean that multi- context does not work. As Kate has already proven, multi-context works. But as long as you have hildon-desktop running in the background, you will not render directly to the screen even if you use Clutter/QtGraphicsView/EGL+OpenGLES2.0/whatnot in your application. When hildon-desktop is running, it is the only one drawing on the screen (with the exception of XVideo). So, killing hildon-desktop is the only way to get direct rendering to the screen at the moment. (We might have something more elegant for this in the future...) Could you clarify what does this mean in practice? Is the performance of 3D rendering significantly slower in applications, for example? I suppose that even if off-screen rendering is used it is still hardware accelerated. Thus, compositing in window manager level should not be a big issue, and we can live with that (for now) if everything just work fast enough. Who needs direct rendering anyway. :) Keeping the compositor around has some performance impact, because after the application draws to an offscreen pixmap (the window), the X server sends Damage events (saying this part of the pixmap changed) to hildon-desktop, and hildon-desktop asks the 3D HW to use this pixmap in a OpenGL texture and draw it to the screen. So, there is some extra delay (maybe 10-25ms) after the application's drawing is visible. Second implication is that you cannot use HW accelerated zooming and moving of textures for the whole graphical pipeline. You can use it for drawing into your window, but when hildon-desktop draws to the screen, it cannot use it (e.g. it cannot say move this content to there). It will just get a big damage area that is updated by updating the OpenGL texture content. Third implication: to save memory, we are using the texture-from-pixmap GL extension to allow the X server and 3D HW share the pixmap data. This means that while 3D HW is accessing the pixmap data (while transferring it to the 3D chip), X server cannot access it. Thus, while the compositor is updating the screen, it is slowing down X drawing. However, it's not mandatory to use texture-from-pixmap, but then you are paying the price in increased RAM usage. BR; Kimmo BR, Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optional build dependencies (e.g. for fremantle)
Hi, Am Dienstag 17 März 2009 schrieb Till Harbaum / Lists: Build-Depends: would-like-to-have-pkg1|harmless-pkg2, would-like-to-have-pkg2|harmless-pkg2, ... I'll give it a try. Ok, first try yesterday was Build-Depends: maemo-version-dev, tablet-browser-interface-dev|maemo-version-dev, ... This did not install tablet-browser-interface-dev. There seems to be some optimization somewhere that makes such a shortcut impossible. So i just tried: Build-Depends: maemo-version-dev, tablet-browser-interface-dev|devscripts, ... Which works fine and pulls tablet-browser-interface-dev in. What about the package to use for this? Such a packet has some limitations: - It must not be a dependency of anything else the build depends upon. E.g. things like libpng-dev will likely always be loaded due to dependencies from the gui libs. - It must always be present - It must be something an application will normally never need to build successfully (it should never become a real dependency) This seems to be true for devscripts. Any other suggestion? Anyway, the osm2go package can now be built by chinook, diablo and fremantle autobuilders :-) Now it's time to add some #if MAEMO_VERSION_MAJOR == 5 into the source code to adapt to the new dialog layout. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optional build dependencies (e.g. for fremantle)
On Wed, 2009-03-18 at 13:50:00 +0100, ext Till Harbaum / Lists wrote: Am Dienstag 17 März 2009 schrieb Till Harbaum / Lists: Build-Depends: would-like-to-have-pkg1|harmless-pkg2, would-like-to-have-pkg2|harmless-pkg2, ... I'll give it a try. Ok, first try yesterday was Build-Depends: maemo-version-dev, tablet-browser-interface-dev|maemo-version-dev, ... This did not install tablet-browser-interface-dev. There seems to be some optimization somewhere that makes such a shortcut impossible. There's no optization of any kind going on here. You request a dependency to be fullfilled and maemo-version-dev does that, so there's no point in also installing tablet-browser-interface-dev. So i just tried: Build-Depends: maemo-version-dev, tablet-browser-interface-dev|devscripts, ... Which works fine and pulls tablet-browser-interface-dev in. What about the package to use for this? Such a packet has some limitations: - It must not be a dependency of anything else the build depends upon. E.g. things like libpng-dev will likely always be loaded due to dependencies from the gui libs. - It must always be present - It must be something an application will normally never need to build successfully (it should never become a real dependency) This seems to be true for devscripts. Any other suggestion? Yes, do *not* do that, it's a major hack, and it might stop working at any time, you cannot control if some of the other Build-Depends will at any point start pulling devscripts (or any phony package you want to add there). The clean and proper way to do this is to branch the packaging, in Debian, packages always target the latest (sid), and often people do backports for old releases (oldstable, stable, etc). regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
xresponse / cnee question re: mimic of multi-key event
Is there a way to use xresponse (or cnee) to mimic a multi-key event such as Alt+F10 ? Thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optional build dependencies (e.g. for fremantle)
Hi, Am Mittwoch 18 März 2009 schrieb Guillem Jover: There's no optization of any kind going on here. You request a dependency to be fullfilled and maemo-version-dev does that, so there's no point in also installing tablet-browser-interface-dev. I meant this. It seems to check if any of the options is already fulfilled before just trying to fulfill them one after the other. Yes, do *not* do that, it's a major hack, and it might stop working at any time, you cannot control if some of the other Build-Depends will at any point start pulling devscripts (or any phony package you want to add there). Yep i know. The symptom will be that the autobuilds start missing features. I should notice that in time. This is imho what the -devel repos are for: See if everything works. The clean and proper way to do this is to branch the packaging, in Debian, packages always target the latest (sid), and often people do backports for old releases (oldstable, stable, etc). No way. I won't branch for fremantle. Either it works with the same package or i won't support fremantle. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optional build dependencies (e.g. for fremantle)
On Mar 18, 2009, at 3:43 PM, Till Harbaum / Lists wrote: Hi, Am Mittwoch 18 März 2009 schrieb Guillem Jover: The clean and proper way to do this is to branch the packaging, in Debian, packages always target the latest (sid), and often people do backports for old releases (oldstable, stable, etc). No way. I won't branch for fremantle. Either it works with the same package or i won't support fremantle. In debian packages get re-built for new targets often, for example nearly every package in stable will be rebuilt for squeeze in the next few weeks because of the update of debian policy. Packaging is hard work and I understand a lot of developers don't like doing it, but if you are interested in making life easier for the users of your software, I hope you will consider building a package for fremantle. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
ESbox doesn't recognize Scratchbox SDK
I wanted to install and use Eclipse to develop for Maemo, so I followed the directions to install ESbox using the links on esbox.garage.maemo.org and get Eclipse Europa, PyDev and ESbox plugins installed, and while they do appear to be installed successfully, I am unable to select a SDK target. Specifically, going to Windows - Preferences and then selecting ESbox - Installed Targets, I click on the New button, and get an Error dialog: No scratchbox 1 or scratchbox 2 SDK was detected; cannot configure targets If I install the pre-made Eclipse with ESbox + PyDev, I select Windows - Preferences and then select Maemo - Installed Targets, and it shows Remote Connections : Nokia Internet Tablet (unknown version 0.0) and when I click on the New button, I get a Cannot install dialog: Cannot install targets for any of the detected SDKs. This is an unusual issue since I can build and run Maemo applications just fine in either the Diablo or Fremantle emulator for x86. Clearly I have the SDKs installed. :-O I have already searched Google but I only found one other person reporting this issue and asking for help (with no response in their case). I am using scratchbox-core 1.0.13 and Maemo SDKs 4 and 5 under Ubuntu 8.10 (running inside of VMware). Scratchbox is installed at the default location (/scratchbox) on the host's filesystem. Does anyone know why ESbox is unable to identify my SDK? Thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
