NOTICE! This is a static HTML version of a legacy LOCI Software ticket.

LOCI projects are now located on GitHub. The Bio-Formats project can be found here.

Ticket #88 (closed defect: fixed)

Opened 2007-03-27T13:45:08-05:00

Last modified 2007-05-02T10:53:45-05:00

Need system to scale selection areas to pixel coordinates

Reported by: sorber Owned by: sorber
Priority: critical Milestone:
Component: visbio Severity:
Keywords: Cc:
Blocked By: Blocking:

Description

The dimensions of the selection grid or highlighting band should be scaled according to the current zoom level, etc. of the display the user is working on (the 'active' display). Currently, OverlayObjects are unaware of such display properties since they may appear simultaneously on multiple displays, but the getSelectionGrid() method is part of OverlayObject. Here are some ideas for scaling the selection grid to the display:

  • Make OverlayObjects aware of the display by passing all objects the active display at each (relevant) mouse event in each OverlayTool

  • Let OverlayTool compute the selection grids of each object. I like this idea--separating the selection of the object from the object itself.

Change History

comment:1 Changed 2007-03-27T13:49:09-05:00 by sorber

  • Owner changed from melissa to sorber

comment:2 Changed 2007-03-27T13:49:33-05:00 by sorber

  • Component changed from bio-formats to visbio

comment:3 in reply to: ↑ description Changed 2007-04-06T12:58:38-05:00 by sorber

Let OverlayTool compute the selection grids of each object. I like this idea--separating the selection of the object from the object itself.

Better yet, let OverlayTransform call a utility class that computes selection layers. The only problem with this idea is that OverlayTransform is not aware of any display. Curtis suggested

  • changing getData() to accept a wrapper object including all current arguments and a display.

This might also involve

  • adding a static method to each transform type that returns whether the transform type cares about changes to the displays' projection matrices, and code in TransformLink (I presume) that would call getData again if a display changes and the new static method returns true.

comment:4 Changed 2007-04-12T14:08:23-05:00 by sorber

Use the TransformLink object now provided to OverlayTransform.getData(...): lnk.getHandler().getWindow().getDisplay();

comment:5 follow-up: ↓ 8 Changed 2007-04-24T13:41:42-05:00 by sorber

Will move getSelectionGrid methods out of OverlayObject and subclasses into a utility class. OverlayTransform.getData will use this utility class to compute selection grids.

comment:6 Changed 2007-04-24T13:42:23-05:00 by sorber

  • Priority changed from major to critical

comment:7 Changed 2007-04-24T13:54:21-05:00 by sorber

Also need to scale the following attributes:

  • Arrow width
  • Polyline proximity circles
  • Proximity threshholds for editable overlays

comment:8 in reply to: ↑ 5 Changed 2007-04-24T18:04:02-05:00 by sorber

Replying to sorber:

Will move getSelectionGrid methods out of OverlayObject and subclasses into a utility class. OverlayTransform.getData will use this utility class to compute selection grids.

Moved these methods to loci.visbio.util.OverlayUtil. Removed these and the computeGridParameters() (now computed during OverlayUtil.getSelectionLayer() if at all) methods from OverlayObject. computeGridParameters() is no longer applicable since overlays use different selection layer types.

comment:9 Changed 2007-05-02T10:53:45-05:00 by sorber

  • Status changed from new to closed
  • Resolution set to fixed

Completed scaling of arrow width, polyine proximity circles. Most proximity thresholds were based on pixel coordinates already, except the selection threshold in PointerTool, now scaled using OverlayUtil.getMultiplier(). Will log further bugs relating to scaling as separate, new tickets.