It looks like I need FREETYPE2 defined for anti-aliasing to work. Freetype 2 is installed, what may be the problem then ? _________________________________________________________________ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp
I'm posting my message for the third time, hoping it will appear on the mailing list. On Mon, 28 Oct 2002 15:05:05 +1100 Carsten Haitzler <raster <at> rasterman.com> wrote: > > this isn't x's job. the wm should handle this. ie it should be a state > machine > and only evaluate its when it goes idle. since X is a buffered > protocol, what > shoudl be happening is > > loop: > read_events() > move... > move... > move... > move... > move... > move... > end_read_events() > move_window() > wait_for_events() > > so all the move events come in in 1 read, since they are buffered. the > window > move only happens when all the events have been read and processed and > the wm > has evaluated its current state. this way the system never fal;ls > behind the(Continue reading)
I post my reply again, hoping it will appear on the mailing list now that I have joined the list. On Mon, 28 Oct 2002 15:05:05 +1100 Carsten Haitzler <raster <at> rasterman.com> wrote: > > this isn't x's job. the wm should handle this. ie it should be a state > machine > and only evaluate its when it goes idle. since X is a buffered > protocol, what > shoudl be happening is > > loop: > read_events() > move... > move... > move... > move... > move... > move... > end_read_events() > move_window() > wait_for_events() > > so all the move events come in in 1 read, since they are buffered. the > window > move only happens when all the events have been read and processed and > the wm > has evaluated its current state. this way the system never fal;ls > behind the(Continue reading)
On Wednesday 21 August 2002 10:37 pm, Owen Taylor wrote: | Peter Kaczowka <peterk <at> ucentric.com> writes: | > Without understanding Render too well, I would guess that some Render | > operations could be sped up using MMX. I'm not volunteering to do it, | > but for anyone interested I think you'll find that using SIMD and coding | > MMX is great fun. But then again I'm old school, and coding assembler | > still strikes me as more fun than say Java. | > | > If MMX is already being used in Render or has already tried, I'm sorry | > to imply that no one has thought of this before. | | I have some code for MMX acceleration of common Render operations | around, that I keep meaning to clean up and give to Keith.(Continue reading)Can someone update, please: have this code found its way into CVS? | | (And there is a lot of optimization of the software fallbacks that can | be done without reference to MMX... you can get maybe 5x improvement | over the current code with plain C, and then MMX gives you an extra 50%.) | | The hardware I've tested on doesn't seem to do burst-mode reads from | video memory, so there is limit to how well you can do when | software compositing directly to the frame buffers. There are definitely | big improvements by carefully managing when things are in video memory, | when in software, and when in both places. | | Regards, | Owen | _______________________________________________
Around 0 o'clock on Nov 12, Vadim Plessky wrote: > | I have some code for MMX acceleration of common Render operations > | around, that I keep meaning to clean up and give to Keith.
Hello. I am trying to use XftDrawString8 to draw slightly translucent
text on the base screen (outside of a window) and depending on where I
call it, either nothing shows up, or else the program seg faults and
crashes.
I call:
XftDrawString8(flash_draw, render_color,
flash_font, 150, 150,
(XftChar8 *) "M", strlen("M"));
Where:
flash_draw = XftDrawCreate(dpy,
DefaultRootWindow(dpy),
DefaultVisual(dpy,
DefaultScreen(dpy)),
DefaultColormap(dpy,
DefaultScreen(dpy)));
dpy = XOpenDisplay(NULL);
flash_font = XftFontOpenName(dpy,
DefaultScreen(dpy), "mono-200");
I have used the rest of this code within the same program to get
successful font viewings within windows defined with XCreateSimpleWindow
with success, and I just don't know enough about the inner-workings of
Xlib/XRender to know what I am doing wrong. I doubt anyone will be able
to figure out my error from this information, but if anybody has sample
code or insight into what might be wrong, it would be much appreciated.
Thanks.
James Fraumeni
(Continue reading)
Sorry to just ask questions, but I was wondering if anyone knew of a way
to get font data into an XImage which could them be displayed. It may
take something like Pango, but I haven't found a way to do so yet. There
might be some way to take font data and convert it into pixel data which
could then be fed into XCreateImage, but I have not found a way to do
that either.
Thanks.
James Fraumeni
This is a write-up of observations on reading through the Xr
and Xc header files and a bit of the sources; I haven't actually
tried using the APIs in practice. I also haven't done a
point-by-point comparison with similar API's; something that
I think would be interesting.
The comments below range from very specific points to some
things which most likely count as "wild ideas".
Regards,
Owen
===
I have some general reservations about using a postscript-type API. I
believe that on the low end, such an API is rather hard for
programmers to use -- they want "draw_circle", "draw_rectangle" type
primitives. And on the high end, postscript needs considerable
extension to be competitive with current rendering models such as
Java2D, SVG, PDF versions.
On the other hand, a postscript-like API is conducive to being able to
write code that targets either Xr or Postscript/PDF, so that's a plus.
On to specific comments.
On Xr:
* Shouldn't there be XrSetSurface (XrState *xrs, XcSurface *surface)
instead of or in addition to XrSetDrawable, XrSetVisual?
(Continue reading)
Around 22 o'clock on Nov 21, Owen Taylor wrote: > This is a write-up of observations on reading through the Xr > and Xc header files and a bit of the sources; Thanks a bunch, Owen. Actual application development experience is something we're pretty weak on... > * I'd like to have XrFormat for gdk-pixbuf's weird default > format: big-endian-premultiplied-rgba. (I can supply the > implementation.) I thought gdk-pixbuf used non-premultiplied alpha. The weird order (RGBA) we can deal with, but the non-premultiplied alpha changes a lot of underlying image composition semantics which are exposed through the API. Xr does separate RGB from A in the API, so perhaps we can make it work. > * I think fonts are one area where following the lead of postscript > is clearly a mistake. Yes, their font selection and character-based APIs are all horribly wrong, but the notion of fonts getting selected and then separately transformed leads to some nice simplifications when doing "weird" things with text. Certainly Xr will always use fontconfig for font selection, and as you've noticed, the current Xr text output APIs are rather limited. Given that X already depends on FreeType, having Xr also expose FreeType apis might be a reasonable solution to part of this problem. Attempting(Continue reading)
On Nov 21, Owen Taylor wrote: > This is a write-up of observations on reading through the Xr > and Xc header files and a bit of the sources; Owen, thanks for your feedback. This is precisely the kind of thing that Xr/Xc need right now. Some of the things you bring up are problems that Keith and I have already discussed a bit in private. Now that more people are looking at Xr/Xc, I'll keep any future discussions here on this list. > I have some general reservations about using a postscript-type API. I > believe that on the low end, such an API is rather hard for > programmers to use -- they want "draw_circle", "draw_rectangle" type > primitives. A toolkit built around Xr could easily add higher-level "primitives" desired by application developers. That said, Xr is still far from complete, but I'm cautious about putting too much into it. The current plan is for Xr to have at least enough functionality to support the rendering needs of PDF 1.4. > * Shouldn't there be XrSetSurface (XrState *xrs, XcSurface *surface) > instead of or in addition to XrSetDrawable, XrSetVisual? Yes, I want XrSetSurface in place of XrSetDrawable and XrSetVisual. I hadn't done this yet since the current implementation of Xc is basically non-existent. I'm about to start on actually building an Xc implementation that allows Xr to be used on X servers missing RENDER.(Continue reading)
RSS Feed9 | |
|---|---|
53 | |
31 | |
52 | |
84 | |
46 | |
29 | |
50 | |
128 | |
52 | |
16 | |
4 |
