I assume that is with one cache per letter, because it shows exactly the ugly text rendering I was talking about. For example look at the space between S and o in Solid - that wouldn't be there in proper rendering.Quote:
Originally Posted by JS987
Printable View
I assume that is with one cache per letter, because it shows exactly the ugly text rendering I was talking about. For example look at the space between S and o in Solid - that wouldn't be there in proper rendering.Quote:
Originally Posted by JS987
Perhaps this XKCD illustrates the issue: http://xkcd.com/1015/
Bad kerning is one of the things that happens if you cache invidual letters - you're essentially making the truetype font be a fixed-width bitmap font, degrading its quality a lot.
Spacing can be changed by tuning of algorithm.Quote:
Originally Posted by curaga
That's the entire point, you can't get proper text rendering by caching the glyphs as images and tweaking an algorithm. You can fake it and maybe get readable text most of the time, but it's not a good solution by any means, and would only work for western languages.
Your statement is multiply false, and the quote you had has nothing to with your statement.Quote:
Originally Posted by JS987
- Wayland is a protocol, Wayland does not composite with any specific method.
- Weston can also composite without GL, using pixman, in pure software.
- There is no indirect rendering. You cannot send rendering commands to the server, because there simply is no protocol to do that.
- Overlays have no implications to indirect rendering, double-buffered rendering, or two-pass rendering.
I think you meant compositing instead of indirect rendering.
False.Quote:
Originally Posted by JS987
Two-pass rendering means that you render your geometry twice, for example first RGB channels, and then alpha channel. Or like some 3D apps, first depth only, and second actual color rendering. This can apply equally well to both clients and servers.
Indirect rendering means that a client sends rendering commands to the server, just like silix explained. Saying only "indirect rendering" does not define whether the rendering is on-screen or off-screen, it can be either one. It can also be single-pass or multi-pass. And it can be single- or double-buffered.
One concept you have not yet abused is double-buffered rendering. In double- (or triple-) buffered, a previous frame is being used while a new frame is being produced. When the new frame is complete, it can be taken into use by switching the buffers (flipping), or by copying. The purpose of double-buffering is to avoid using an incomplete frame. This too can apply equally well to both clients and servers, and it actually must be used in both to guarantee perfect output at all times.
Compositing means forming a big picture from several images. You can do it multi-pass or not. You can do it indirect or direct rendered, if you are running under another graphics server, provided the graphics server supports them. Compositing could be single-buffered, so the user will see incomplete composites flashing around, or it can double-buffered so the user will always see a good picture.
All these four concepts are completely orthogonal, and furthermore none of these mandates desktop effects.
Unequal space between glyphs is minor bug. It doesn't really matter. Chromium and Firefox also have this bug with Arial on my machine. There are more serious bugs on Linux. I had to uninstall almost all non-Microsoft fonts because they look like crap.Quote:
Originally Posted by curaga
When I say Wayland I mean Wayland protocol or Wayland compositor.Quote:
Originally Posted by pq__
Rendering is process of generating image. Compositing is also rendering. Weston also does rendering using compositing.
2 pass rendering can mean many things. Indirect rendering can mean many things.
If image output from applications is composited by compositor, applications do indirect rendering.
It seems this is what Kristian demonstrates here: http://youtu.be/L8zwnqKysfI?t=19m45sQuote:
Originally Posted by JS987
So it can basically switch dynamically between sending a buffer to the compositor, and displaying that buffer directory onto the screen (if it's completely visible/uncovered by other windows).
Are you talking about the ligature mechanism? Because that isn't as complicated as you are describing. A font designer will include the ligatures for all 'ligaturiseable' pairs (such as 'fi', 'ff', 'ffi', 'Th', etc -- there aren't that many, and some fonts do not include them all) as discrete entries in the font. If a typesetting system is clever enough, it will recognise such pairs and just substitute the original pair for the special glyph in its output. It is not more subtle than that.Quote:
Originally Posted by curaga
Beyond that, any typesetting system will obviously need to take account of a font's kerning tables to get correct inter-letter spacing. Some mechanism would need to be implemented for that, but I'm assuming that it is since it's so fundamental.