In reply to Lee Brown <[EMAIL PROTECTED]>
>
>On Tue, 19 Dec 2000, [EMAIL PROTECTED] wrote:
>> thoughts?
> Bloat. Bloat . Bloat.
hm. ok, so here goes a more detailed analysis.
why? is it better to have to implement the same thing over every
single program that wants to put boxes modified internally in a
generic way? right now, i think ggiPutBox and ggiGetBox are functions
with very little practical use. i can only see them being used in a
generic way to copy the contents of the visual for later 'paste.' or
does anybody calls 'ggiPutBox' before any call to 'ggiGetBox' to do
something meaningful? the buffer they return is next to useless per
se, unless you happen to know its format and your program only plans
to support that format and that format alone. otherwise, you will have
to implement 'ggiPixelToBox' yourself.
for my purposes, the very existence of ggiGetBox and ggiPutBox could
be considered "bloat," since i have absolutely no use for them as it
stands now.
for font rendering the routines would be of great use. consider
1) get glyph
2) map glyph to anti-aliased black-and-white pixel* buffer
to render, just ggiPixelToBox and ggiPutBox. but what makes it
interesting is the following: if you want to change the colors of the
rendered glyph, all you have to do is to modify the pixel* locally and
repeat ggiPixelToBox and ggiPutBox. it will save you *at least* 100
function calls, as noted before. i think there is no other way to
render fonts fast if you want generic color support.
i could probably find many more meaningful examples (animation comes
to my mind), but i guess this one suffices. the message is that
ggiPixelToBox is a useful routine, and not having it effectively puts
a strain on the usefulness of ggi. it is not a wrapper; it is not a
bell or a whistle; it seems to be a necessary function if you want to
abstract the underlying buffer structure and at the same time you want
to have performance.
i can be wrong. but somebody will have to show me how can i render a
terminal screen fast with support for generic background and
foreground font colors without having to spend a ridiculous amount of
memory for caching all possible combinations of colors for every
single character, or to consider support for every buffer format in
existence and those to be created. and if nobody can show me, then ggi
is too weak for a crappy terminal emulator. if somebody shows me how,
so much the better, i'll go on and implement it! (to the happiness of
all ;)
>How's that term coming? Still slower than a snail on a treadmill?
it's quite usable, i'm writing in 'verdana.ttf' right now (10 pixels
wide, console). but reminds me of my old 486es running x... switching
from antialiased to monochrome helped a lot. i'm quite happy with it
and use it as my standard terminal. it won't see the outside world if
it can't compete with rxvt.
--
Cesar Augusto Rorato Crusius __o __o __o __o __o
Stanford University _`\<, _`\<, _`\<, _`\<, _`\<,
e-mail:[EMAIL PROTECTED] (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_)
www.stanford.edu/~crusius
o _ _ _
__o __o __o __o /\_ _ \\o (_)\__/o (_)
_`\<, _`\<, _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/
(_)/(_) (_)/(_) (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
He who sacrifices functionality for ease of use
Loses both and deserves neither
