Re: Graphics issues

[Eric Wasylishen]

On 2011-08-30, at 3:38 AM, Andreas Schik wrote:

> Hello Eric,
> thanks forlooking inthose issues.
> 
No problem.

> Am 30.08.2011 05:17, schrieb Eric Wasylishen:
>> Hi Andreas,
>> 
>> On 2011-08-29, at 5:08 AM, Andreas Schik wrote:
>> 
>>> Hi there,
>>> on the weekend, I update GNustep from SVN (trunk) and did a completely
>>> fresh installation. Since then, I have several graphics issues.
>>> 
>>> 1. When using gnustep-art, GWorkspace does not display file icons. I am
>>> using a viewer in symbol mode. While the navigation control in the upper
>>> part displayes correctly, no file/directory icons are shown in the lower
>>> part (symbol view). This does not apply to to gnustep-cairo. Here, the
>>> correct file type icons are displayed.
>> 
>> This is fixed now. I made a mistake when modifying NSCachedImageRep last 
>> week (deleted the -draw method when I shouldn't have).
> OK, I'll try asap.
> 
>>> 2. With both backends, it seems that images which do not have a
>>> resolution of 72x72 dpi are not displayed correctly. Details:
>> 
>> As far as I know, the current behaviour is correct and matches what Cocoa 
>> does.. [snip]
> I would not doubt that this behaviour is correct. I just saw that it was
> different than before my update.

>> 
>>> - 72x72 is of course a value that applies to the very notebook I am
>>> using. Don't know whether this applies to other machines as well.
>> 
>> The GNUstep gui is rendered at 72x72dpi by default, so it applies to all 
>> machines, [snip]
> Does this mean, that images are always supposed to have 72x72 dpi,
> otherwise they will be scaled one way or the other?

For images which are part of the UI, yes. The exception is when you scale the 
coordinate system, whether through a scale factor for the whole UI, or say the 
page zoom control in TextEdit. e.g. if you set the UI scale factor to 4, 
NSImage will use the 288dpi versions I made of some of the default graphics 
(arrows, scroller knob, checkbox/radio buttons, etc.) and they'll be copied 
pixel-for-pixel to the screen. Of course, everything will look huge since the 
bitmaps are 4x the size of the original versions :-)

>> The only exception is on Windows, where if you increase the system DPI in 
>> the Windows control panel, GNUstep will respect that. It does that by 
>> computing a scale factor, so 96 DPI in windows (the default) = 72 DPI in 
>> GNUstep.
>> 
>>> - Images are scaled in strange ways. I observed 75x75 dpi images to be
>>> upscaled in the Y direction only.
>> 
>> Hm, that shouldn't happen.
> At least, that was what my bare eye told me. The flower seemed stretched
> into the Y direction only.
> BTW, the physical resolution of my screen is 75x72 and to me it seems
> that the EtoileLoge is transferred pixel-wise to the screen. This would
> again explain why it is enlarged in the Y direction, but in the X direction.
> But on the other hand, you say that the physical relution should be
> ignored by GNUstep. How do the -compositeToPoint: methods work?

Hm, interesting. 

The important thing with the methods -compositeToPoint: and -drawAtPoint: is 
they call [self size] to determine how large the image should be. -size returns 
the image size in points, so for bitmaps it's derived from the pixel size and 
the dpi recorded in the file. 

compositeToPoint will do a pixel-for-pixel copy if the image's DPI is 72, the 
destination point ends up at a integral pixel coordinate, and the UI scale 
factor is 1. The exact behaviour of compositeToPoint is a bit confusing because 
it ignores the CTM, but it respects the UI scale factor.

I'll just paste the code for reference:

- (void) compositeToPoint: (NSPoint)aPoint
                 fromRect: (NSRect)srcRect
                operation: (NSCompositingOperation)op
                 fraction: (float)delta
{
  NSGraphicsContext *ctxt = GSCurrentContext();

  // Calculate the user space scale factor of the current window
  NSView *focusView = [NSView focusView];
  CGFloat scaleFactor = 1.0;
  if (focusView != nil)
    {
      scaleFactor = [[focusView window] userSpaceScaleFactor];
    }

  // Set the CTM to the identity matrix with the current translation
  // and the user space scale factor
  {
    NSAffineTransform *backup = [ctxt GSCurrentCTM];
    NSAffineTransform *newTransform = [NSAffineTransform transform];
    NSPoint translation = [backup transformPoint: aPoint];
    [newTransform translateXBy: translation.x
                           yBy: translation.y];
    [newTransform scaleBy: scaleFactor];
    
    [ctxt GSSetCTM: newTransform];
    
    [self drawAtPoint: NSMakePoint(0, 0)
             fromRect: srcRect
            operation: op
             fraction: delta];
    
    [ctxt GSSetCTM: backup];
  }
}


>>> There were also images with 90x90 dpi
>>> being downscaled.
>> 
>> I think that's expected. e.g. a 90x90 pixel image with a DPI of 90x90 would 
>> have a size of 1x1 inch or 72x72 points, and if the GUI is at the default 
>> DPI of 72, that maps to 72x72 pixels (so in other words the image is 
>> downscaled.)
>> 
>>> - Example is Etoile's MenuServer. While the middle part displays
>>> correctly, the left and right edges as well as the logo are distorted.
>>> The middle image is 72x72 dpi the others are 75x75 dpi.
>> 
>> I wasn't able to get MenuServer to work, but I tried drawing the 
>> EtoileLogo.tiff image in GSTest and it appeared correctly (a bit blurry and 
>> scaled up because of being 75dpi). So I'm not sure what is going wrong here.
> What bothers me is that noth images have more dpi than GNUstep/my
> screen, but the one (EtoileLogo) seems upscaled while other seems
> downscaled. I have the impression that in the case of Etoile, the image
> is simply transferred pixel
> 
>>> 3. gnustep-cairo does not handle themes very well. Neos, at least has
>>> some glitches, e.g. missong knobs on scrollbars. Not a major problem,
>>> though.
>>> 
>> A few images in the Neos theme just need to be set to 72dpi. The scroller 
>> knobs are actually being drawn, but they're really hard to see because they 
>> are 96dpi and being downscaled.
> I see.
> 
>> Sorry about the trouble created by having images with a DPI != 72 being 
>> scaled. It's inconvenient but I think it's correct in the long run.
> Well, it might be correct, but it confused me anyway :-) I was thinking
> that images for screen elements were transferred pixel-wise, ignorig the
> DPI. In that case they would need more or less screen estate, but would
> not up or down scale.

Hopefully my explanation above is clear :-)

> Anyway, thanks for the xplanation.
> 
> Ah, btw, does GNustep support SVG images?

Yes, via ImageMagick (which itself wraps librsvg). :-) Currently the 
ImageMagick wrapper we have only rasterizes at 72dpi though, but it should be 
easy to fix that.

Cheers,
Eric