862803 - handle new (hidpi-aware) image viewer scaling option

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Jonathan Kew [:jfkthame]]

In bug 857089, we're proposing to modify the ImageViewer click-to-resize behavior, which currently provides two sizes, "shrink to fit" and "full size", and the ability to toggle between them.

With the increasing prevalence of high-dpi displays, the proposal is to introduce a third size, "device pixels", which will scale the image such that one image pixel equals one device pixel (rather than one CSS pixel, which is the existing full-size view).

I understand SeaMonkey uses the toggleImageSize API, and has a checkable Fit to Window option in the context menu. (See bug 857089 comment 12.)

So should we modify the behavior of toggleImageSize, such that it cycles through the three "standard" scales (on hi-dpi systems), or leave its behavior untouched and possibly add a new API to switch between the three sizes (as in the ImageViewer's click-event handling)?

If we do modify toggleImageSize, this may have implications for how it is exposed in SeaMonkey UI (a single checkable menu item no longer makes sense, if there are three sizes to consider).

Comment 1

[[e-mail]]

How easy is it to determine whether there are two or three sizes in the cycle?

Comment 2

[[e-mail]]

I'm leaning towards wanting toggleImageSize cycle as if the image was clicked on its top left pixel. Anyone who wants the old behaviour can call the appropriate method manually, e.g.
if (doc.imageIsResized)
  doc.restoreImage();
else
  doc.shrinkToFit();

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to [e-mail] from comment #1)
> How easy is it to determine whether there are two or three sizes in the
> cycle?

If window.devicePixelRatio is 1.0, there'll only be two sizes (because the "full CSS px" size and the "device pixel" size would be the same); if it's > 1.0, there'll be three.

(Oh, except that you'd have to compensate for the effect of page zoom level on devicePixelRatio; IIRC, devicePixelRatio changes as the page is zoomed.)

Of course, if the full size image fits within the window, there's only one size (or two, if device pixels and CSS px are different), as shrink-to-fit is no longer applicable.

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to [e-mail] from comment #2)
> I'm leaning towards wanting toggleImageSize cycle as if the image was
> clicked on its top left pixel. Anyone who wants the old behaviour can call
> the appropriate method manually, e.g.
> if (doc.imageIsResized)
>   doc.restoreImage();
> else
>   doc.shrinkToFit();

Sounds reasonable to me. I'd suggest filing a separate bug to change the behavior of toggleImageSize in core, as we landed bug 857089 without modifying that; and then you can do whatever is needed on the SeaMonkey side here.

Comment 5

[[e-mail]]

So, if I have understood it correctly, the click behaviour toggles between CSS size, device size (if different) and shrink-to-fit size (if different) in ascending order. It would be quite tricky to emulate this in script, so "fixing" toggleImageSize would be appreciated. Assuming this happens, I would probably want to switch to a plain "Zoom Image" menuitem (conveniently I don't think we use a Z accesskey yet) to invoke the new behaviour.

Comment 6

[[e-mail]]

(In reply to Jonathan Kew from comment #3)
> (In reply to comment #1)
> > How easy is it to determine whether there are two or three sizes in the
> > cycle?
> 
> If window.devicePixelRatio is 1.0, there'll only be two sizes (because the
> "full CSS px" size and the "device pixel" size would be the same); if it's >
> 1.0, there'll be three.
> 
> Of course, if the full size image fits within the window, there's only one
> size (or two, if device pixels and CSS px are different), as shrink-to-fit
> is no longer applicable.

Ah, so there might be one, two or three sizes, depending on device/CSS px and image natural size? I guess imageIsOverflowing doesn't suffice for this.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to [e-mail] from comment #5)
> So, if I have understood it correctly, the click behaviour toggles between
> CSS size, device size (if different) and shrink-to-fit size (if different)
> in ascending order.

Right. (And then loops back to the smallest of the three.) You should be able to observe this behavior in the latest Firefox nightlies if you have a display configured for a high-dpi setting (>96dpi) on Windows, or a Retina-display Mac.

(In reply to [e-mail] from comment #6)

> Ah, so there might be one, two or three sizes, depending on device/CSS px
> and image natural size?

Yes. If I'm not missing any factors here, I think the only case where (new) toggleImageSize would -not- actually do anything would be if

(a) imageIsOverflowing is false;
(b) imageIsResized is false;
(c) window.devicePixelRatio is 1.0; and
(d) window.fullZoom is 1.0.

In this case, the image is fitting entirely within the window; it's already at full size; device-pixel size would be the same; and the page zoom hasn't been used to change it.

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to [e-mail] from comment #2)
> I'm leaning towards wanting toggleImageSize cycle as if the image was
> clicked on its top left pixel.

Wouldn't the center pixel be preferable to top left, for a zoom feature that is not associated with a specific click position?

Comment 9

[[e-mail]]

(In reply to Jonathan Kew from comment #8)
> (In reply to comment #2)
> > I'm leaning towards wanting toggleImageSize cycle as if the image was
> > clicked on its top left pixel.
> 
> Wouldn't the center pixel be preferable to top left, for a zoom feature that
> is not associated with a specific click position?

It's what the existing code does, and I didn't want it make it too hard for you.

Comment 10

[Jonathan Kew [:jfkthame]]

If those are the only reasons, I'd vote for changing it - I don't think it'd be hard to zoom about the center instead of the top-left, and IMO it'd be a nicer UX.

(FWIW, note that bug 857089 already changed the behavior for actual clicks, to maintain the position of the clicked point on the image, which old code wasn't doing.)

Comment 11

[Stefan A. Möller]

> So, if I have understood it correctly, the click behaviour toggles between
> CSS size, device size (if different) and shrink-to-fit size (if different)

IMHO showing a standalone image in CSS size does not make sense at all. First, without a HTML page there is no CSS. Second, why would anybody want to see a standalone bitmap type image (JPEG, PNG, etc.) being scaled up. It will always look blurry.

It would be sufficient to be able to toggle between shrink-to-fit size and device size only. If someone really wants to view the image zoomed-in, then he can use the existing ctrl++ zoom.