Older blog entries for pabos (starting at number 2)

Quixotic : Repainting, Paths & Fonts

My foray into 2d graphics and typography is provining to be very stimulating. I've been exploring how to implement the rendering pipeline for my Quixotic project recently.

I have a vague notion in my head that when redrawing an image, an efficient and complete redraw will do better overall than using logic and data structures to minimize redraw areas. Undoubtedly this is a simplification but I persist in thinking it while trying to avoid it at the same time. Mostly this is a combination of prior experience and inexperience. Some years ago I made some assembly language demos in DOS which often involved blitting some image to the screen as fast as possible to draw some sprite, animatated fire or the like. The concept which has stuck with me is "wait for the refresh signal and blit like mad". Still, anything beyond basic 2d vector shapes will require bitmap intermediaries so blitting will undoubtedly be a very import component of the whole solution. The inexperience factor is my unfamiliarity with how data structures behave when random lookups, caching, and computations all play variable parts in a time constrained redraw. 'Behave' sounds like an odd word to use to my ears but I think it describes it well enough since I can think of what the data structures should do but I don't have a feeling for what I they should do.

Since I'm trying to get some experience with data structures suitable for editable, easily renderable objects, I've been playing with paths and trying to decide on a good way to do partial path renderings. Redrawing the entire path if the path's bounding box is dirtied seems inelegant at best and, more importantly, the inevitable chained redraws that result would be a killer. For example, redrawing a path may cause a redraw of another path which partially overlaps it, which may cause the redrawing of text touching it, etc. This becomes enormously expensive very quickly, especially if the paths are filled with some form of bitmap paint (ie. gradient, image, pattern), masked, filtered and then composited. For that matter, since I'd like to support very large images redrawing even a single path can be expensive.

The problem I'm having is that I can't find a good way to represent partial paths. I've recently read that libart has a bounding box for each segment of its Sorted Vector Paths (SVPs) which could help at the expense of much higher memory use and the need to continually regenerate the SVP of paths being edited. However, my target canvas is in physical coordinates, not pixels, and I think SVP coordinates are already rasterized to pixel coordinates. I'll have to check into this further.

After trying to form all kinds of data structures for this purpose, I suddenly realized that clipping the paths within the regions of the canvas to be redrawn to that region would effectively bound the redraw to a limited area and draw only the portions of the path that I need. SVPs may prove useful here.

Mailing Lists and Journals

Since subscribing to desktop-devel and gtk-devel a few weeks (months?) ago I often have the desire to respond to some particular topic. I usually don't though because I feel like there are too many issues I don't understand and I find that when I think of my initial reactionary response, a few days after I might have posted, it is usually less insightful or helpful than I originally felt it was. It seems as though this Advogato journal will be a good middle ground alternative for me - an opportunity to give somewhat thoughtful, somewhat reactionary responses.

I think this is possible because Advogato is intentionally personal - my journal is my journal. Often on mailing lists I have the impression that everyone feels they must argue their particular case; as a result discussion quickly degenerates into criticism of who was unfair to whom, who was misrepresented, who wasn't consulted, the list goes on... Mailing lists are public forums where each voice tries to be heard above another. Posts which provoke response co-opt the entire mailing list. A journal on the other hand, is also public, but it invites rather than challenges. If people want to hear what I have to say they come to read it. If they disagree, its in a less confrontational manner and we can discuss it. If they really dislike it, they can avoid it.

Now having said that some journals can also be used in the same way as flames in mailing list and I have vague recollections of skipping journals like that when I browsed through Advogato journals before joining. Additionally, when I joined two days ago, I explored the site a little more thoroughly and for the first time discovered the "Recent Diary Entries" link which I had previously assumed was a heading to the journal entries below it. When journals are viewed this way, its a little more like a mailing list where you just get a barrage of messages irregardless of who wrote them so you may end up reading more inflammetory pieces. Still, even in this case, the nature and frequency of journal postings doesn't build up to the level of flame threads because the responses are less frequent and not directly linked into a theme-like hierarchy. Dilution makes it less potent and therefore less irritating.

I wrote some more about a specific issue on desktop-devel but the html form entry won't accept the entire journal so I'll just post this for now. I'll have to look into other ways of entering a journal soon.

My first post.

A preview of some intial topics I'll likely write about

  • Quixotic
    A desktop publishing canvas. Initial focus will be on low level source layout and performance experiments for the rendering and caching systems. Tests will probably begin with path rendering. The canvas is intended to be composed of modular, and therefore replaceable components, at as many layers as is practical and worthwhile to do so. Two examples of where this might be useful are a replaceable text layout system and a replaceable canvas view system. Primary canvas views will be a freetype/libart/Xshm view and an Xft/Xrender view.

  • Verso
    A fully versioned file system within a file system - primarily for Drex.

  • Drex
    A desktop publishing suite. Depends on Quixotic and Verso so comments will likely be high-level descriptions and planning notes for the immediate future.

  • unnamed: notes & associations
    A program for taking unstructured notes quickly and applying arbitrary associative relationships between elements at any point in time afterwards.

  • Gnome
    Comments on, suggested improvements, enhancements to, etc. Discussion regarding a tentative series of articles detailing how to develop software using the Gnome libraries. The tentative title of the series is "the Exemplary Gnome". As the title suggests the idea would be to create articles that capture the best practises for particular libraries with a heavy use of examples. Part of the appeal may, or may not, be that it would be written by someone who is coming to the Gnome libraries for the first time himself.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!