Hi,
looking at evas_engine_*_font_draw(), I wonder why we render the font first
and scale the result afterwards.
Shouldn't we render the font in the target size directly, in order to
avoid loss of resolution?
Thanks,
Bernhard
---
This SF.Net
The following little patch adds support for the new style name of the
framebuffer device with a fall-back to the old one.
(/dev/fb/0 vs. /dev/fb0)
Regards,
Bernhard
--- evas-cvs-orig/src/lib/engines/fb/evas_fb_main.c
+++ evas-cvs-modified/src/lib/engines/fb/evas_fb_main.c
@@ -450,8 +450,14 @@
First post of this one got moderated. Hopefully there won't be a dupe.
I've been experiencing a tiling problem for the Eterm backgrounds on
my AMD64 box.
Yeah... it was getting on my nerves too.
I hacked in some debug, and looking at it I saw that in
parse_pixmap_ops() the tiled token isn't
samuel wrote:
sorry for any interpretation of clutter on mailing list.
i am relatively new to programming so learning things correctly the
first time greatly concerns me.
i cannot find the meaning of con in ecore_con. the word.
is it an acronym, is it a shortened word?
googling finds
On Mon, 13 Sep 2004 14:53:43 +0200 "Nemec, Bernhard"
[EMAIL PROTECTED] babbled:
Hi,
looking at evas_engine_*_font_draw(), I wonder why we render the font first
and scale the result afterwards.
Shouldn't we render the font in the "target size" directly, in order to
On Monday, 13 September 2004, at 16:23:07 (-0400),
Nicholas Jones wrote:
A bit more information... The filename being passed to load_image
has 'tile' not 'tiled' as the token for the geometry setting.
On my x86 box, tiled backgrounds work with the same default
menu.cfg for Eterm, but on the
