lardman | # 521 | 2010-09-27, 18:05 | Report

Atm it's scanning all the time and pushing the shutter button down half way makes it focus if the auto-focus is off. I agree though that we should have some kind of graphical and audio indication that something has been scanned successfully.

I'm also going to add the option to use the shutter button to focus then perform processing (for e.g. 3s after the button is pressed), which should save cpu cycles and make the normal display smoother (no need to have the decoder threads running in the bg all the time.)

I noticed this today, but what I saw was that the list of plugins came up pretty quickly, but then when I was tapping buttons there was no graphical response (though eventually the plugin did open.)

This is especially odd as the plugin I wanted to use was the plain "display text" one, which should be pretty lightweight. I need to look into this as it's not acceptable to have delays like this.

dragly | # 522 | 2010-09-27, 18:10 | Report

The graphical response missing is probably due to something set up wrongly in the GUI. Either in the custom delegate used for painting, or just in the selection settings for the table view.

If there is a delay in other plugins than Informed Individual, then there is something seriously wrong. Maybe there is some lag after closing the pipeline? I'll try to look into it when I have the time, as well.

lardman | # 523 | 2010-09-27, 18:23 | Report

Depending on the complexity of the plugin, we might need to thread the plugin callbacks, especially for plugins that perform web-lookups.

dragly | # 524 | 2010-09-27, 21:38 | Report

If I remember correctly, the network requests made in Qt are done in a separate thread. That's why you need to connect a slot for the network reply, whenever that returns. The problem with the Informed Individual plugin is that it currently does not give any user feedback before it receives a network reply, but it does not block the GUI, though.

In other words, there is no GUI-blockage when you hit the Informed Individual plugin. Just try to go back to scanning after pressing the plugin button.

On the other hand, making the clickAction() of a plugin into a threaded signal/slot system might be useful to avoid plugins locking up the whole application.

lardman | # 525 | 2010-09-28, 13:22 | Report

As an aside, I've just pushed the skeleton of a plugin to handle Python plugins. I need to push PythonQT to extras-devel asap and then work out the structure of Python plugins and fill in the useful code, but I have at least started (finally! )

The reason for using a plugin to host multiple plugins is to stop it being necessary for people to include the additional PythonQT startup overhead and dependencies unless they are using a Python plugin.

Anyway, I'm working on it

lardman | # 526 | 2010-09-28, 21:37 | Report

Just looking at the code to add in the alternative shutter button action and wondering how much of the startup time is due to using OpenGL?

Dragly have you done any benchmarking? Any other thoughts about getting a functional UI up faster?

As another aside, I wonder if we should load the plugins in a thread/in the bg somehow to prevent the slowdown that will probably occur when they are loaded the first time a barcode is scanned?

---

Last edited by lardman; 2010-09-28 at 21:39.

protrek | # 527 | 2010-09-28, 22:31 | Report

After installing Mbarcode to my N900 the camera would not work. I only get a errormessage internal error, camera will be closed.
Had to uninstall mbarcode and addons.

Wikiwide | # 528 | 2010-09-28, 22:50 | Report

Strange... I have mbarcode 0.2.2-4, the latest version, and experience no such problems whatsoever.

lardman | # 529 | 2010-09-29, 08:41 | Report

Probably not an mBarcode problem tbh as it works for everyone else. Rebooting tends to fix a non-behaving camera.

If it really does seem to be linked to mBarcode, I'd be interested to see the output of the camera app from the command line when you try to run it, and also the dmesg and DSP logs.

lardman | # 530 | 2010-09-29, 08:42 | Report

I've been looking at FCamera, which uses nice overlays for the camera controls and histogram but doesn't use OpenGL. I'll try converting the UI to use plain Qt overlays and see what the performance is like.

Edit: OTOH it may use OpenGL itself, in which case I won't bother - I'll look and see!

No, it doesn't use OpenGL (so there's still the chance it will be quicker). Instead it uses the overlay layer provided by the framebuffer hardware. I suppose it should be possible to encapsulate the overlay stuff in a class and then be able to easily swap between OpenGL and framebuffer overlay. The FCamera people have wrapped the overlay stuff in a class - see OverlayWidget.cpp in the FCamera Garage project.

---

Last edited by lardman; 2010-09-29 at 09:13.