Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Reply
Developer
Posts: 188
Registered: ‎01-27-2012
My Device: playbook
My Carrier: ...

Poor rendering performance, seeking some tips

Hi All,

I should start by saying I am a self taught novice programmer and I don't have much experience with rendering things...

I have made a pdf reader for the playbook using Qt c++, based on the Qt4 demo's example that comes with the  poppler open source pdf library.

I am finding that the performance is lacking, particularly when it comes to the pinch to zoom function I just implemented and also for things like adjusting the size of the TOC or other QDock widgets, the speed is unacceptable. It takes a couple of seconds to reload/render the pdf page after each zoom request so you can imagine the lag time when trying to zoom in on anything with a pinch... Its not so bad if I use a spin box to select a zoom factor but its terrible when trying to use pinch.

I am wondering if using QOpenGL would make a difference here? I really don't know anything about QOpenGL except that it will try to use the devices GPU to speed up rendering?

I am using Splash with poppler for the rendering currently.

So I guess my question is, should I start looking into openGL for rendering the PDF's to increase performance, or does Qt already use openGL for rendering behind the scenes?

I just don't want to waste a bunch of time trying to learn how to use openGL if its not going to help out with performance on my playbook....

Does anyone know how the pinch to zoom function in the current pdf reader that comes with the pb is so smooth?

Any and all advice is greatly appreciated!

Cheers,

Jon

 

 

Developer
Posts: 133
Registered: ‎03-28-2011
My Device: BlackBerry 9900 & PlayBook
My Carrier: Bell

Re: Poor rendering performance, seeking some tips

The PlayBook's current PDF reader is written in AIR by Adobe. Since they created both AIR and the PDF format, they likely have the know-how for how to render it smoothly. PDF rendering has been done for over a decade on machines without OpenGL, so I doubt it's requirement.

OpenGL can make a significant difference in the rendering speed, and I've done some OpenGL work within Qt on the PlayBook, but I've since migrated to use QML backed by OpenGL. So Qt can use OpenGL for rendering, but likely not with QWidget-based components. Based on your description, I'm not clear what you're use for the rendering component. Consider turning into a QDeclarativeItem so that you can move it into QML and have Qt render it using OpenGL.

Founder of Pulsecode Inc. and taab
Authomator - Two-factor authentication codes on BlackBerry 10 - http://www.xitijpatel.com/ - Follow @xitijpatel
Is there a helpful or useful post in this thread? Click the thumbs up on it so that other people can find it more easily!
Developer
Posts: 188
Registered: ‎01-27-2012
My Device: playbook
My Carrier: ...

Re: Poor rendering performance, seeking some tips

Yes, Qt widgets support opengl no problem, there is even a QGLWidget class I could use... I am just not sure if its a direction thats worthwhile as it will take me some considerable learning/time to change what I have now...

I am not interested in using qml as it introduces its own performance issues, thats why I chose to use strait c++ from the start, to keep it snappy!

In any event, I can just use a standard control for the zoom factor, its just I sure would like to utilize the pinch gesture as I am sure the users will be pinching away on it with no joy Smiley Very Happy

I was on the airplane the other day and watched in amazement as the fellow beside me kept trying to pinch to zoom in on the map on the airplane TV in the back of the seat... Smiley Very Happy

Cheers,

Jon

 

Retired
Posts: 499
Registered: ‎05-07-2012
My Device: developer
My Carrier: developer

Re: Poor rendering performance, seeking some tips

As you already suspect, don't go down the route of openGL.  This is a huge project  to get around an issue, and isn't what you really want to be coding.

 

Ultimately the issue is with your pdf library or how you're using it.  Does it have a zoom capability?  If so, make sure your pinch handlers are calling it.   If not, your library doesn't suit your needs.  "It takes a couple of seconds to reload/render the pdf page" -- how much work is being done in the pinch operation?  The way you word this, it sounds like you are re-reading the full pdf in order to display one small part.  Make sure you are only doing a zoom action.

 

Test that the issue is with the zoom itself, not with many repeated zooms.  Add a temporary button or other way to do a single zoom, and check how responsive that is.  Perhaps you are doing too much work while in the process of zooming: if there is a new zoom location, are you still processing intermediate locations?  If so, perhaps you want to be skipping intermediate steps and animating instead.

 

"not interested in using QML as it introduces its own performance issues"... While I'm a fan of doing much in C++, QML is a very nice way to define the initial layout and is often much cleaner and easier to read than the corresponding C++.   I'd like to hear more about performance issues with using QML over C++.

 

Optimization is primarily an art of discovering what to optimize - and conversely, what not to bother optimizing.   Code in the way that is clearest to you.   When something is inefficient, there are tools to help find where the issue actually lies.   But often you can just step through in the debugger to get a sense for what step is inefficient.   Generally if it's inefficient it's because it's doing more work than it needs to do, and once you zero in on it, you may see exactly where it's wasting its time.   Sometimes it's for other reasons, like running out of memory.

 

Hope this helps... let us know your progress.

 

Stuart

 

 

 

 

Developer
Posts: 188
Registered: ‎01-27-2012
My Device: playbook
My Carrier: ...

Re: Poor rendering performance, seeking some tips

Thanks for the reply Stuart!

I will reply inline below.


smacmartin wrote:

As you already suspect, don't go down the route of openGL.  This is a huge project  to get around an issue, and isn't what you really want to be coding.

 

Ultimately the issue is with your pdf library or how you're using it.  Does it have a zoom capability?  If so, make sure your pinch handlers are calling it.   If not, your library doesn't suit your needs.  "It takes a couple of seconds to reload/render the pdf page" -- how much work is being done in the pinch operation?  The way you word this, it sounds like you are re-reading the full pdf in order to display one small part.  Make sure you are only doing a zoom action.

I am using the only open source pdf lib I am aware of, poppler. I copied the zoom function right out of the Qt demo that comes with it, it basically just reloads the individual page you are viewing with the zoom factor you set. So it is not re-loading the entire pdf but rather just the page. I did not bother trying to get it to zoom in on the coordinates where the pinch occured, but rather just zoom in the page. When I use a standard control to zoom it still hesitates about a second or two to re-render the page so I dont think it is a matter of my method or other work being done, rather I think perhaps this is just the nature of the poppler libs. I will put a post on the poppler mailing list and see if anybody there has any insight into better zoom performance before I pursue this issue any further...

 

Test that the issue is with the zoom itself, not with many repeated zooms.  Add a temporary button or other way to do a single zoom, and check how responsive that is.  Perhaps you are doing too much work while in the process of zooming: if there is a new zoom location, are you still processing intermediate locations?  If so, perhaps you want to be skipping intermediate steps and animating instead.

 

"not interested in using QML as it introduces its own performance issues"... While I'm a fan of doing much in C++, QML is a very nice way to define the initial layout and is often much cleaner and easier to read than the corresponding C++.   I'd like to hear more about performance issues with using QML over C++.

I agree! I have come from the symbian Qt world and have developed apps with strait Qt c++ and qml and have ported both types to the playbook successfully. While the UI's are much better for mobile, and nicer to develop with qml, there is a definite performance loss when compared to strait Qt c++. Everything from page loading, scrolling, data storage, etc, takes longer in qml. On new high end devices its not so noticeable but on older symbian and android devices you can really see the issue. Symbian wouldn't even support their 3rd and 5th generation devices for the symbian qml components because the performance was terrible. Even the original playbook qml port had very sketchy scroll performance in lists, page animations etc. The performance of qml on the playbook is much better now that the port has matured though.

Optimization is primarily an art of discovering what to optimize - and conversely, what not to bother optimizing.   Code in the way that is clearest to you.   When something is inefficient, there are tools to help find where the issue actually lies.   But often you can just step through in the debugger to get a sense for what step is inefficient.   Generally if it's inefficient it's because it's doing more work than it needs to do, and once you zero in on it, you may see exactly where it's wasting its time.   Sometimes it's for other reasons, like running out of memory.

 

Hope this helps... let us know your progress.

 

Stuart

 

 Thanks for taking the time to give me a detailed response!

Cheers,

Jon

 

 




Highlighted
Retired
Posts: 499
Registered: ‎05-07-2012
My Device: developer
My Carrier: developer

Re: Poor rendering performance, seeking some tips

Any response from the popplar board?

There's still a chance the issue is somewhere in your code; often just stepping through the code makes this clear.

 

If you consider this thread closed, please accept one of the posts (even your own) as the solution.

If not, how can we help?

 

Stuart