image by ericwa; please observe ‘textedit’ info window and its preferences on the right side

Given the delay since the last update, this should be a lengthy post. Since I’m writing this at a very late hour, it won’t be.

Shortly after the last update, I added painting of images, as long as they’re 32-bit. I finally began considering the ‘gstateless’ variant of the backend, where the OpalGState class would be removed, as well as the dependence on GSContext family of classes. The idea was that all state switching could be managed by Opal. Unfortunately, Fred explained how AppKit treats GState and the idea does not map well to Core Graphics’s one-graphics-state-stack-per-context model.

Then I went to Dublin for a job interview. When I got back, I was (shall we put it mildly) highly distracted by the experience of another travel to a foreign country. After that, a two week summer camp where I almost no progress was done. A place with no good internet connectivity (except several cafe bars) would be tolerable were there a place for me to unpack my laptop as permanently as possible. Unfortunately, any such place was a computer classroom, and my accommodation was anything but appropriate for the activity. Other distractions of a summer camp also came in play, such as ‘Hey, come here, let’s work on the movie.’

Would coming back home change things? Well, after a massive headache due to low amount of sleep during the last day of camp and during the return trip, after a cold, and after a toothache, I finally got to work.

Thanks to a lot of help with Eric on the Opal side (and even a bit on the backend side, because he’s cool like that), we now have font rendering! Hooray!

Unfortunately, you may notice that the above images feature rectangles again, instead of icons. This time they’re yellow rectangles instead of red ones. Why? -compositeGState:... method is being called after -DPSimage:... was called, so we end up with a ‘not-implemented’ marker for -compositeGState:....

What’s next? Well, wrapping up as many things as possible by the end of the week, when GSOC ends.

Yep, I could and should have done far better this year. Oh well.

Thanks to a fix that Eric applied to Opal’s handling of painting CGBitmapContext->CGImage on top of another CGContext, the backend now actually paints something sensible on a doublebuffered window. Hooray!

Well, actually, it only paints something sensible on a menu window. And as soon as the backend has to paint an update, for some reason the updated stuff is painted (mostly) upside down. I’ve tested with the Gtk theme, and the in-window menus also seem to be updated upside down.

I also seem to be unable to get menu items to be wider despite various hacks when it comes to fonts. It seems that OpalFontInfo‘s -widthOfString: is not used at all, and a series of calls to -advancementForGlyph: is instead performed, with no effect on the width of the menu whatsoever.

I’ll explore further what’s wrong with both of these issues tomorrow; preparing for a job interview today will take the rest of this day.

Note: I did not commit my yesterday’s work described above, as it mostly consists of hacks that have no useful effect onscreen. Eric’s changes to Opal, combined with a change of #if 0 to #if 1 in gnustep-back’s OpalSurface‘s init method do produce some of the visible changes described above.

Looking at the existing [...GState DPS...] methods and comparing them to the Core Graphics functions, it looked like implementing the backend will be as much of a cakewalk as I originally presumed.

Turns out it is not meant to be.

(Today’s text is a report as much as it is a way for me to contemplate next steps. It’s a noisy stream of thoughts. Sorry about that.)

All is drawn, but nothing is seen (a.k.a. doublebuffering)

The Cairo backend contains code intended to render into a backing store and then draw the content on screen when requested to do so by X. (Presumably, also to blit the content when it updates.) Theoretically, it should be trivial to add this functionality: add a new CGBitmapContext, redirect all drawing into this new context, and then blit this content on screen when requested.

When creating the surface that targets the screen, one gets a gswindow_device_t* that describes the X11 window. To tell the rest of the gnustep-back that this surface can handle its doublebuffering (although it really can’t), we set this gswindow_device_t‘s gdriver to self, and we add flags GDriverHandlesExpose and GDriverHandlesBacking to its gdriverProtocol bitmask. This is done only if the surface is not NSBackingStoreNonRetained.

(From the above description one would think by default, backing stores would be already handled elsewhere in gnustep-back. Unfortunately, although it seems like gnustep-back might be trying to handle the case where the surface does not handle X11’s Expose event nor does it handle having the backing store, it does not do so, at least not properly.)

So, I’ve tried to do it. All drawing is redirected to a CGBitmapContext, and then in -handleExpose I’m trying to blit the content on the X11-backed Opal surface. It seems that Opal currently has some issues with the following code (i.e. I get everything drawn in pale yellow):

- (void) handleExposeRect: (NSRect)rect
{
  CGRect cgRect = CGRectMake(rect.origin.x, rect.origin.y, 
                      rect.size.width, rect.size.height);

  CGImageRef backingImage = CGBitmapContextCreateImage(_backingCGContext);        
  CGContextDrawImage(_x11CGContext, cgRect, backingImage);  
  CGImageRelease(backingImage);
}

Debug output from Opal suggest it’s going through all the expected dance moves: creating that image, converting it into destination context’s colorspace, et al. I’ll poke Eric to see if he has a better idea of what’s going wrong.

An interesting behavior is that if I simply don’t redirect drawing to the bitmap context, then I get some content on screen. Despite not having an actual backing store. Maybe GDriverHandlesBacking has side effects? I’ll have to dig in more.

(Oh, and gotShmCompletion methods seemed like they might be related. No change if I implement them.)

Everything is flipped

When I first got some content on the screen, it turned out that GNUstep’s zero-zero seems to be based on top-left corner of the drawable — opposite from what Opal expects.

So as a first attempt I went in and implemented matrix functions. While things don’t get drawn in the appropriate place yet, it seems like I’m on the right track. The thing that worries me is that I’m not sure what’s the orientation of DPS matrix as opposed to the orientation of the CG matrix. Also, I’m now overriding DPS methods and not calling super, yet there’s a bunch of code in GSGState‘s implementation that makes me think this is not such a good idea. DPS functions seem to be maintaining matrix state; hopefully they don’t ever use it directly. If they don’t, then it might be safe to simply override the getter for the matrix.

To be able to reset the Opal matrix to the identity (or, near-identity, considering it’s also flipping the coordinate system), I’ve also added a method to Opal that allows this precise operation. This is an extension over what Apple provides: Apple provides absolutely no way to set the CTM (presumably, this stands for current transform matrix) directly, which makes only a little bit of sense. I don’t see a good reason this functionality is not provided to developers. (I can think of one that’s just a tiny little bit good.)

Menus have a single item

Now all I get in a menu window is a single menu item. Drawn in place of the menu window’s title.

Meaning, drawn on a completely incorrect place. I’m not really sure if this is a menu item drawn in an incorrect place, or if this is caused by the fact that -compositeGState:..., which seems to permit blitting one GState‘s backing surface’s content on top of another GState‘s content, is not implemented.

If this is so, this may prove very troublesome to implement without adding further hacks into Opal. Core Graphics seems to provide no real way to copy a portion of a context on top of another context, apart from using CGBitmapContext.

Fonts. Oooh, boy.

Cairo backend does a lot of stuff when it comes fonts. A lot, lot of stuff. I wonder why most of that is not exposed to the rest of gnustep-back, so I’ll probably be moving that out of the Cairo backend and into an additional module within gnustep-back called fonts, or something like that. Or perhaps even into the existing gsc module.

Just taking a quick look, art backend seems to be supporting just fonts with the .nfont extension (explaining Helvetica.nfont), but I may be wrong. Taking a quick look at xlib backend, and it seems to be doing something similar to the cairo backend.

It’s going to be a pain to implement fonts, especially to do it properly. I’ll have to think about how to deal with refactoring this — cairo backend is popular and accidentally breaking it won’t be looked at kindly by the community. Still, it’ll be worth it.

Unless it turns out I should have dealt with Opal. In which case Cairo backend’s implementation will stay Cairo backend’s implementation, and Opal backend will leverage Opal for its text needs.

Yes — just as the title of this section implies, I’m not sure what I’m talking about.

Other upcoming steps

Among other things, I’ll look into getting image painting to work. GNUstep does a lot of things with images, so seeing the images might help me figure out what’s going on more easily.