[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz] xupdf
From: |
Tuomas Lukka |
Subject: |
Re: [Gzz] xupdf |
Date: |
Tue, 21 Jan 2003 14:01:06 +0200 |
User-agent: |
Mutt/1.4i |
On Mon, Jan 20, 2003 at 08:42:23PM +0200, Matti Katila wrote:
> On Mon, 20 Jan 2003, Tuomas Lukka wrote:
> > Hi, now it seems that the texture lazy loading and caching is working -
> > please test.
>
> Someone needs to find the bug which dumps my xupdf first ;)
Like I said, does PaperQuad put stuff on stack still? Might be just that.
> > What should we aim for: should we try to incorporate spatial (pp) features
> > into this?
>
> Can you be more specific? Like text writing?
The canvas and user texts on it -model.
> Jump to different subject - can we profile what we see in view. Pp isn't
> very usable after few links anymore because it's very much too slow in my
> machine. I think our testers report also very soon that it's too slow
> since they have 600MHz computer there. Can we profile out the bad parts
> of rendering?
There are several ways of attacking this problem; unfortunately, profiling
is one we don't have. This is because OpenGL rendering is asynchronous.
The thing to do would probably be to
1) use GLScreen.timeRender to time the rendering of a given vobscene
2) start changing things, to see what the problem is.
- change resolution down / up. If that changes the speed much, then
you have a fill rate problem.
- remove parts of the scene, see what causes the greatest slowdown
In OpenGL it can be quite easy to get a LOT of speedup because the drivers
are optimized for certain paths and if we can keep to them, things will be nice.
Tuomas