Subject:
|
Re: Ldglite must be faster
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 5 Sep 2002 20:51:00 GMT
|
Viewed:
|
999 times
|
| |
|
|
"Steve Bliss" <partsref@yahoo.com> skrev i meddelandet
news:utvenuov1aga5rp4k9e0uftgqk4cbpertd@4ax.com...
>
> > Or, for that matter, it could be a separate process (LDRAW Graphics • Server),
> > which might be easier to port to other systems. Then I can send • WM_COPYDATA
> > messages to it :-))
>
> Hmm, I think you just exceeded my knowledge level. How would that work?
> That is, how would having a separate process empower handling
> WM_COPYDATA messages? By "separate process", do you mean making a COM
> object? For VB use, that would nearly be as good as an ActiveX control.
It shouldn't use WM_COPYDATA, that was just a joke.
No, I meant: Just another program which gets commands through Windows
messages, pipes, shared memory, files on disk, or any other of all the
possible methods.
Not a DLL, not an ActiveX, not a COM-object, but a plain Application.
It would probably have to render to a tempfile, though...
> call to a DLL would be to render some LDraw code. Something like:
> RenderLDraw(hDC, sLDrawCode, sWorkDir)
It would probably be better to 'render' to an in-memory buffer (windows
bitmap?), supplied by the main application, and let the main application
handle the real painting.
> My final thought is that it would be good if the DLL could produce one
> or more structures populated with the heightmap and/or the ... ummm ...
> part-map(?).
What info should be in the height map?
> A 'part-map' would be a record of which part (actually, source line from
> the sLDrawCode parameter) is rendered at each pixel. This could be used
> for hit-testing, to allow the client program to support (some) mouse
> interaction.
Interesting. Just doubles the memory consumption...
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery/index.htm
|
|
Message has 1 Reply:
 | | Re: Ldglite must be faster
|
| (...) Ah. We've got that already - ldglite in offscreen mode. (...) That's the downside. (...) Right. That's what I thought device contexts basically were. Maybe I'm misremembering; sorry. (...) The final Z values of each pixel. I'm not sure how (...) (22 years ago, 5-Sep-02, to lugnet.cad)
|
Message is in Reply To:
| | Re: Ldglite must be faster
|
| (...) An ActiveX control would be very useful for "all those little helper programs", where the programmer really doesn't want to worry about all the standard Windows grunge. Especially if the ActiveX control could add value over a disconnected (...) (22 years ago, 5-Sep-02, to lugnet.cad)
|
39 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
|
|
|
|
