Subject:
|
Re: Ldglite bug report (Was: Portable Ldraw system)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 16 Aug 2002 21:29:03 GMT
|
Viewed:
|
1604 times
|
| |
|
|
In lugnet.cad.dev, Jeremy H. Sproat writes:
> In lugnet.cad.dev, Don Heyse writes:
> > Could you give me some feedback on the experimental menu
> > (still right click) in this recently escaped beta version of ldglite?
> > http://news.lugnet.com/cad/?n=8490
>
> Yow! Incredibly slow. :-/
>
> It seems to be constantly re-drawing the screen when the dialog is active.
> It's also pegged my CPU utilization at 100%.
>
> Hmm, double-clicks don't do anything. Or maybe it's just not polling for
> mouse clicks fast enough -- it took me 3 or 4 tries with the OK button to
> change directories.
>
> Weird -- the redraw process "bleeds through" to the top-most window when I
> cover up LDGLite.
>
> It's also just a little bit slower -- my test model takes 21 seconds to
> render. What's really odd is that when the mouse cursor is over the window
> it takes 45 seconds.
Some of that really sounds like driver problems to me. What does
ldglite print out about your opengl drivers? Maybe you're not using
the Microsoft Software opengl drivers after all, but rather some brain
dead half implemented OEM drivers. Do you know what graphics board or
chipset you've got? It's not that crappy orphan Savage-3D chipset
is it?
Also, is your .ldr test file anything you could share? I'd like to see
how your display times compare with with the same file running on my
test PCs.
> With how slow the redraw rate in opengl is, I would not recommend using it
> to render your control widgets.
>
> How about supplying a platform-neutral API for the controls and window
> management code, so that native controls can be used? This would help the
> look and feel tremendously, helping it look like (for example) a mac app
> when running on a mac.
Yeah, I've been thinking about that for quite a while now. I guess
I'm gonna have to go there. I just don't really want to make it harder
to build the program. Using a platform neutral toolkit would almost
certainly make it harder because I'd have to build the toolkit
first. I don't think there are any out there that supply binaries
for all the platforms I'm currently supporting.
> I don't know anything about the glut API, so I can't help you there. I
> would recommend, however, that you render the model into an off-screen image
> buffer which is then copied to the screen; this should eliminate most of the
> redraws.
I think I did render to the back buffer at one point, but I commented
it out because I like to see what's going on. I suppose I could revive
that code though. Maybe make it an option. And now that you mention it,
I think ldlite has such an option. I'll have to dig in and find the
hooks.
Don
|
|
Message has 1 Reply:
 | | Re: Ldglite bug report (Was: Portable Ldraw system)
|
| (...) GL_VERSION = 1.1.0 GL_EXTENSIONS = GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture GL_VENDOR ='Microsoft Corporation' GL_RENDERER ='GDI Generic' GL_RGBA_BITS: (8, 8, 8, 0) GL_DEPTH_BITS = 32 GL_STENCIL_BITS = 8 Buffer Swap Mode = 2 (...) (...) (22 years ago, 16-Aug-02, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Ldglite bug report (Was: Portable Ldraw system)
|
| (...) It seems to be constantly re-drawing the screen when the dialog is active. It's also pegged my CPU utilization at 100%. Hmm, double-clicks don't do anything. Or maybe it's just not polling for mouse clicks fast enough -- it took me 3 or 4 (...) (22 years ago, 16-Aug-02, to lugnet.cad.dev)
|
63 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
