Re: Object Graphics fonts [message #39664 is a reply to message #39240] |
Tue, 08 June 2004 14:15   |
Karl Schultz
Messages: 341 Registered: October 1999
|
Senior Member |
|
|
"Rick Towler" <tsehai@comcast.net> wrote in message
news:F_lxc.57351$3x.8757@attbi_s54...
>
> "Michael Wallace" wrote...
>>> I have found that rendering to the screen provides far better results
> than
>>> rendering to IDLgrBuffer (IDLgrBuffers are rendered using the software
>>> renderer). And better graphics adapters will do the anti-aliasing for
> you
>>> (check your graphics adapter settings). Render to the screen, read
the
>>> window, and save as PNG.
>>
>> Hmmm... interesting. Things do look better using and IDLgrWindow,
>> however is it possible to use the hardware rendering without a display
>> screen? This plot will be part of an automated process, so there will
>> never been a screen available.
Is it possible that using IDLgrWindow is giving you better results only
because the dimensions are larger? The default IDLgrBuffer size is 640x480.
Aside from the frame buffer size difference, I don't see how hardware
rendering would produce a better display, where text is concerned. I could
see how turning on line or polygon or even full-screen AA might help lines
and polygons, but text is now drawn with texture maps and I'm not sure that
graphics cards should be messing with texture contents other than performing
the usual interpolations.
Anyway-
IDL 6.0 was the first release with the FreeType-based texture mapping
rendering for IDLgrText. We've made a few bug fixes and a lot of
improvements in this area for IDL 6.1. Without an exact testcase I can use
to compare 6.0 and 6.1 text rendering, I can't tell if Michael's specific
concerns are addressed or not. I looked through the bug database and found
that I fixed a problem that sounds very much what Michael is describing.
The problem would occur when the model space was scaled unequally and a
non-default baseline and updir was used. In any event, 6.1 may address the
problem.
Karl
|
|
|