Subject:
|
Ldglite bug report (Was: Portable Ldraw system)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 16 Aug 2002 17:17:16 GMT
|
Viewed:
|
1623 times
|
| |
|
|
In lugnet.cad.dev, Jeremy H. Sproat writes:
> Okay, this is a quick and dirty list, just what I've observed or confirmed
> today:
>
> Menu - The right-click menu is very confusing. Why not put this in the menu
> bar and standard dialog boxes? File browser is confusing, as is file filter.
>
> Menu - File browser skips files, I can't load my file if it falls within the
> last three slots in browser submenu. I had to delete files from my
> LDRAW\MODELS directory before I could see my test file.
Yeah I've known about the problems with the menu for quite a while now.
I refuse to go to a 1.0 release number until I fix that. However since
I'm running out of release numbers I've actually started to do something
about it. 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
I really wish someone would create some nice control widgets written
in C (not C++) that use opengl for all the drawing. This would meet
my portability goals for ldglite. But I've been waiting a long time
and it just isn't happening. It looks like I'm gonna have to do it
myself. Rats!
> Window - Program starts with window bounds matching screen resolution; I'm
> missing the title bar due to my task bar. Why not start at a smaller size,
> or have it remember window size between sessions?
I've gotten into the habbit of always putting a -v3 on the command line
because that's the size I like. I even put it into the registry for
when I load a file straight from lugnet. But I did that manually
because I don't want to put unportable registry code in ldglite. I
suppose I could invent a new LDRAW meta-command for this and stick
it in the ldliterc.dat file. But then I'd have to come up with a
license for the meta-command. ;)
> Command-line Option - option -Bn doesn't work, bg always 15 (white).
Hey, you're right. I wonder when I broke that. I think it used
to work at one point.
> LEdit Mode Toggle - Why not put this in the menu?
That's a good idea, and an easy one too. Thanks.
> Input Keys - ALT-F4 doesn't close the window.
That's an easy one, but is it any sort of standard beyond windows?
CUA perhaps? Could you point me to a page where this is documented?
I'm guessing that pressing that key combo generates some Windows
message that's ignored by the glut library. If so, I could catch it
myself in the ldglite keyboard handler when running on a Windows
platform, or everywhere if it's a standard in wide use.
> Redraw - Clears screen during redraw for any small reason - a tooltip from
> the task bar triggers this, sometimes a mouse movement will. When this
> happens, after waiting for the redraw, it redraws again from the beginning.
> Can become an endless cycle in some circumstances. Must kill program from
> task manager.
>
> Redraw - Won't restart redraw in middle of redraw, must wait until it's
> finished. You can't input a command during a redraw.
>
> LEdit Mode - OpenGL text takes too long to redraw, why not use native font,
> or a subwindow that doesn't need to redraw constantly?
> > Do you have any numbers to back that up?
>
> I stand corrected. LDGLite renders faster than LEdit on my box.
>
> I'm running on an AMD K6-500 with 192 Mb RAM, 1024x768x24. In LEdit, my
> test file took 43 seconds; in LDGLite, 17 seconds (per redraw). I note that
> it took 4 redraws in LDGLite before I could do anything, though, so it
> really took more than a minute before I could do anything with it.
Ah, Now we're getting to the speed issue. It looks like it's not
actually the redraw speed, but the response time that's the issue.
LEdit scores high in this area. It's quite good at responding
to key strokes right away and then fixing the rest of the display
later. The glut Opengl library expects the redraw times to be in
frames per second and not seconds per frame so it's not designed
to be interruptable by keystrokes. That makes this one a tough
problem to solve. I can either break up the display loop somehow,
or figure out a way to make it redraw so fast I don't need to
worry about it.
> With all my whining, though, I want to point out that the renderer in
> LDGLite produces the best-looking, most crisp LDraw images of any other
> renderer.
Thanks, I like the way it draws things, especially with the -q command
line switch for antialiased lines, but there's some really neat features
in ldview that I've gotta incorporate before I'd even think about
claiming to have the best-looking output.
Anyhow, thanks for the feedback. If you think of anything else, don't
keep it a secret.
Don
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
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
|
|
|
|
