Re: mbarcode
 

Hi guys,

Sorry about the lack of updates from my side. Been a bit busy, and it seems like maemo.org didn't want to notify me about new replies to this thread before today.

Just wanted to point out that I messed around with the overlay stuff for quite some time before going down the OpenGL path. The problem is that the xvimagesink overlay, as lardman points out, doesn't behave like expected. I experienced two outcomes which neither were positive. Either xvimagesink took over the whole window, like lardman wrote about just now, or the overlayed buttons or icons got a black box background.

If we figure this out without using OpenGL, it would be the very best solution. But if I'm not wrong, the FCamera app has these problems as well. The overlay there is cluttered with a black box background on all controls.

I guess we have to decide if we want smooth camera movement or want to avoid black boxes around the controls. Personally, I find the boxes very ugly, but if the OpenGL method still is giving bad performance even after lardman's latest improvements, I guess it might be better to go with performance.

What do you guys think?

Re: mbarcode
 

Quick reply...
I suppose black boxes are not that bad. Performance is more important, in my humble opinion. Maemo Camera has black stripe behind its white controls, at least on my device.

Re: mbarcode
 

No, I've concluded that OpenGL does the job and really it doesn't look like it adds much to the startup time.

It would certainly be useful for startup time to move the GStreamer pipeline setup, etc., to a thread so that the UI is brought up sooner. I'll take a look at this.

Re: mbarcode
 

Glad to hear that. I hope we can stick with the OpenGL UI and still have good performance. It looks much better than what at least I am able to achieve without it.

I'll try to debug some more myself and see if I can figure out why there is some delay between the scan finishes and the results window is shown. Unless you've found anything on this, lardman?

Re: mbarcode
 

The one thing I spotted was that there's a 0.5s delay between the scan finishing and the plugin list being populated. The plugins are asked every 0.5s whether they can handle the barcode in question (ResultsWindow::checkPlugins()), and originally the timer callback was used to do the first call. I've commited a fix for this by simply calling the checkPlugins() immediately as the timer is setup.

I will do some more digging to see what else might be causing problems. Is the results window created at startup? It might be worth having it loaded and hidden to make the transition quicker (though this would cause slowdowns at startup - argh! ;))

Re: mbarcode
 

Ah, of course. I guess you're right. The timer is probably causing some of the delay. Calling the slot directly is probably a good idea :)

The ResultsWindow is loaded at startup, yes.

Re: mbarcode
 

Might be worth adding a one-shot timer slot for that then, so that it's not added to the startup lag. Alternatively it should be possible to do in a thread, as there shouldn't be any access issues (even though threads are not supposed to access GUI elements.)

Re: mbarcode
 

Just loaded the most recent version from dev, loving it. The auto scan without hitting the shutter worked great in the local thrift store, and after I added the US amazon link...wham results (resale is bleh put that book back) lol

Looking great!

Re: mbarcode
 

Right, I have just uploaded libpythonqt, which is a package of PythonQt (http://pythonqt.sourceforge.net/). Now I just ;) need to get the pythonqt wrapper plugin working (and with that test whether libpythonqt works too).

Re: mbarcode
 

Right, the plugin has also compiled successfully, which is nice. I'll do some testing this evening on both the python plugin and external DBus plugin and (crossing fingers) let you know whether things are working + post some skeleton example plugin codes.

Really need to split up that QRcode plugin now I think about it again, and implement mecards....