Hi,
I have been thinking about our performance on large molecules and
about how we can improve the situation. I have also been looking at
how other applications handle this and think I have come up with a
nice solution. I think we should add a third render function to the
engines that is called when the view is being moved. This will only be
called when the mouse is down and should be fast. Then when the mouse
is up the normal renderOpaque and renderTransparent functions can be
called.
This would allow simple engines to simply call renderOpaque if they
wanted to. More complex functions could store their display in a
display list and others could simply not render if they were too
costly. I think on big systems especially getting rid of transparency
during movement could help us a lot. As will storing the display in
display lists that can be invalidated.
Then we can hopefully improve interactivity with large molecules and
still have nice rendering when the display is static. It should even
allow us to improve the static display, i.e. I could do depth sorting
on the transparent ring engine to get it to render correctly for
nanotubes etc. These changes will also require an addition to the
GLPainter to turn off dynamic scaling during quickdraw. I need this
for the improved axes display too - the cylinders are turned into
lines…
So I propose adding setDynamicScaling(bool) to the GLPainter (true for
what we currently do, false to turn off) and renderQuick(PainterDevice
*) to the engines which will do the quick rendering. Dynamic scaling
would be disabled for the quick render function by the GLWidget. I
think we should permit raw GL calls in the renderQuick function but
discourage any transparency.
What do you guys think? Good idea? Suggestions and/or improvements? I
think as we have it now we have two mutually exclusive goals - high
quality rendering for looks and fast rendering for interactivity.
Hopefully this solution can remedy this situation.
Thanks,
Marcus
I like this idea but I propose that we just make one function and add a
parameter that is like RenderFlags and is just a bunch of ENUMs that
tell what the current state is. This would be more convenient I believe
and would be more extensible in the future if we want to add more on/off
flags.
–
Donald
(Tue, Dec 11, 2007 at 02:48:35PM -0500) “Marcus D. Hanwell” mhanwell@gmail.com:
Hi,
I have been thinking about our performance on large molecules and
about how we can improve the situation. I have also been looking at
how other applications handle this and think I have come up with a
nice solution. I think we should add a third render function to the
engines that is called when the view is being moved. This will only be
called when the mouse is down and should be fast. Then when the mouse
is up the normal renderOpaque and renderTransparent functions can be
called.
This would allow simple engines to simply call renderOpaque if they
wanted to. More complex functions could store their display in a
display list and others could simply not render if they were too
costly. I think on big systems especially getting rid of transparency
during movement could help us a lot. As will storing the display in
display lists that can be invalidated.
Then we can hopefully improve interactivity with large molecules and
still have nice rendering when the display is static. It should even
allow us to improve the static display, i.e. I could do depth sorting
on the transparent ring engine to get it to render correctly for
nanotubes etc. These changes will also require an addition to the
GLPainter to turn off dynamic scaling during quickdraw. I need this
for the improved axes display too - the cylinders are turned into
lines…
So I propose adding setDynamicScaling(bool) to the GLPainter (true for
what we currently do, false to turn off) and renderQuick(PainterDevice
*) to the engines which will do the quick rendering. Dynamic scaling
would be disabled for the quick render function by the GLWidget. I
think we should permit raw GL calls in the renderQuick function but
discourage any transparency.
What do you guys think? Good idea? Suggestions and/or improvements? I
think as we have it now we have two mutually exclusive goals - high
quality rendering for looks and fast rendering for interactivity.
Hopefully this solution can remedy this situation.
Thanks,
Marcus
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It’s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
On Dec 11, 2007, at 3:05 PM, Donald Ephraim Curtis wrote:
I like this idea but I propose that we just make one function and
add a
parameter that is like RenderFlags and is just a bunch of ENUMs that
tell what the current state is. This would be more convenient I
believe
and would be more extensible in the future if we want to add more on/
off
flags.
Wouldn’t this result in lots of ifs and elses? What I had in mind was
a rendering pipeline that was tuned purely for speed so that we can
take some shortcuts, save to display lists etc. Then keep the current
functions which could focus more on getting better rendering without
needing to worry so much about speed.
Not sure what the advantages of adding the enum are and whether this
would lead to a more complex rendering function that would be
inherently slower? Wouldn’t the function then need to be aware of the
enums too? I figured we have GLWidget optimise for fast rendering in
this mode and it would be quite specialised.
On Dec 11, 2007, at 3:05 PM, Donald Ephraim Curtis wrote:
I like this idea but I propose that we just make one function and
add a
parameter that is like RenderFlags and is just a bunch of ENUMs that
tell what the current state is.
I totally don’t understand this. I think what you’re saying is that
we’d have:
Render(… enum RenderState) {
switch (RenderState) {
case (transparent):
…
}
}
If so, this is the C version of C++ method dispatch. It doesn’t break
the API to add new methods. If you like, that’s adding to the enum. We
have two entries right now (renderOpaque and renderTransparent).
Marcus is adding a third. We can add a fourth and a fifth (or more) if
we wish in the future.
In general, the C++ version is usually faster, since you’ve reduced
conditional statements.
Cheers,
-Geoff
It was just a suggestion. Do we need to worry about ABI compat issues
at all? I guess probably not as long as we add and not remove.
Sounds like good stuff.
(Tue, Dec 11, 2007 at 09:15:14PM -0500) Geoffrey Hutchison geoff.hutchison@gmail.com:
On Dec 11, 2007, at 3:05 PM, Donald Ephraim Curtis wrote:
I like this idea but I propose that we just make one function and add a
parameter that is like RenderFlags and is just a bunch of ENUMs that
tell what the current state is.
I totally don’t understand this. I think what you’re saying is that we’d
have:
Render(… enum RenderState) {
switch (RenderState) {
case (transparent):
…
}
}
If so, this is the C version of C++ method dispatch. It doesn’t break the
API to add new methods. If you like, that’s adding to the enum. We have two
entries right now (renderOpaque and renderTransparent). Marcus is adding a
third. We can add a fourth and a fifth (or more) if we wish in the future.
In general, the C++ version is usually faster, since you’ve reduced
conditional statements.
Cheers,
-Geoff