Paul Kienzle wrote: > On Thu, Aug 30, 2007 at 02:19:47PM -0400, Michael Droettboom wrote: >> Paul Kienzle wrote: >>> Hi all, >>> Before I look to deeply into this myself, is there anyone working on it >>> already? Is there anything I need to look out for when implementing it? >> I've made a few excursions down that road -- >> >> For bitmap font rendering, the entire math expression is first laid out >> in a greyscale bitmap buffer, which is cached and then transferred to >> the main plot bitmap. It was already that way when I got here, and I >> assume that's an important optimization (so the text doesn't have to be >> re-laid-out when the plot is zoomed/panned). I say "perhaps" because I >> have no data to back it up, and don't know if that came out of profiling >> or not. >> >> There are a few key low level pieces that are missing for rotation: >> >> - FT2Font.draw_glyph_to_bitmap does not support rotation. This would >> have to be added, or there may be a way to use >> set_text/draw_glyphs_to_bitmap which does support rotation. However, >> that would make rendering the entire expression to a single buffer much >> more difficult. > > Adding rotation to draw_glyph_to_bitmap looks like the easier option... > >> - The horizontal lines are all drawn as filled rectangles aligned to the >> pixel grid, directly into the font buffers. That will probably have to >> be pushed upward into the Agg layer to get good line drawing at >> arbitrary angles -- but that also makes caching the bitmap a little more >> difficult. So maybe it makes sense to implement our own Breshenham's >> algorithm in ft2font.cpp. > > ...but if we need to go into agg anyway, why not use Agg's font handling > capabilities directly?
Perhaps historical reasons. I wonder if they're still relevant. >> All this will be affected by John's proposed refactoring of the >> backends, of course, which has kind of kept me off of it in a "wait and >> see" kind of mode. Right now, each backend has a custom interface to >> communicate with mathtext -- whereas mathtext should simply be calling >> the same low-level methods on all backends to get its job done. That, >> of course, would make this buffer optimization harder (or at least it >> would have to be thought about differently). > > I haven't followed the refactoring proposal close enough to know if it > makes more sense to implement mathtext via freetype in agg or to use > freetype directly like you are currently doing. Once that decision is > clear, we can certainly prototype the handling of rotated text in the Agg > backend. > > Presumably this will have to be repeated for Cairo. Cairo already works, as of a few weeks ago, it no longer uses bitmaps for mathtext rendering. (I should have been more clear earlier -- my brain has it filed in with the vector backends, though obviously it has a resterizer.) >> Let me know if you decide to implement this and let me know if you have >> any questions about the code. Otherwise I'm happy to add it to my queue. > > I can get by for now with limited text rotation, at least until the > backend refactoring has settled. That may be a while (re: John's latest message). In the meantime, I'm going to explore, as he suggested, how bad doing a raster rotation would look, as that's the easiest path forward. Cheers, Mike ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
