Bug 51688 - [Qt] Np API plugins rendering issues.
Summary: [Qt] Np API plugins rendering issues.
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: S60 Hardware S60 3rd edition
: P2 Blocker
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2010-12-28 14:21 PST by Prasad
Modified: 2011-01-31 09:35 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Prasad 2010-12-28 14:21:30 PST
we are facing very high performance issues with Camera plugin. The functionality of the plugin is to launch Camera and display the viewfinder data
on a user specified window in the widget. 

This plugin is implemented as windowed plugin. Viewfinder data is displayed as follows

on loading the plugin we invoke startViewFinderBitmaps() api provided by CCamera. This api invokes the callback function with each frame provided as
bitmap data. We convert this bitmap data into QPixmap in the callback. A signal is emitted from the callback to the plugin with the QPixmap. This QPixmap has
to be drawn into user specified window. To do this we invoke repaint() api in the slot and draw the pixmap in the overloaded paint implementation.
Comment 1 Prasad 2011-01-06 14:00:23 PST
Related QtWRT Bugzilla error ID: http://bugs.nokia-boston.com/bugzilla/show_bug.cgi?id=6748
Comment 2 Benjamin Poulain 2011-01-28 17:16:47 PST
Shouldn't that be assigned to yourself?
Comment 3 Janne Koskinen 2011-01-31 02:51:52 PST
(In reply to comment #2)
> Shouldn't that be assigned to yourself?

I think Prasad is error manager and not a coder. I agree it is difficult to see the issue without having the badly behaving plugin.
I could hazard and say the images are large that come from the viewfinder and it takes a while to copy these from buffer to buffer.. maybe an isolated test case without the camera so it can be reproduced. Playback a large animation or something.
Comment 4 Benjamin Poulain 2011-01-31 08:29:50 PST
We need more info to work on this bug or prioritize it. I close this bug for now and we will reopen when having a test case or more info about the problem.
Comment 5 Janne Koskinen 2011-01-31 09:35:07 PST
What we need is how much data you expect to get through? A test case would be great.
Have you tested this on Symbian native app and you have reliable performance difference with Symbian app vs. QtWebkit?

The viewfinder on camera is implemented as DSA so the data doesn't actually have to be copied to client app.
So I'm not sure if you even can get acceptable frame rates with copying it first to bitmap and back to VG image for blitting.

We have an augment reality app that draws on top of viewfinder. And there we had to copy the data from viewfinder in order to be able to draw our components on top of it (due to VG changed how you do DSA) and we couldn't get acceptable frame rates at all. Our application is fullscreen app so 200x200 viewport might be ok provided that framerates are not very high.

There is open Qt bug that should give massive boost with removing one copy from the pipeline QT-2505.

The other alternative and would be my recommendation is to not to copy the images at all. However something tells me that you need to copy them over... reason?