[Task]: Hop Web context dialogs - investigate SVG rendering

[mattcasters]

What needs to happen?

Rendering the context action dialog content as SVG could help deliver a faster and crisper result on Hop Web.

Issue Priority

Priority: 3

Issue Component

Component: Hop Web

[mattcasters]

Investigation Findings: Context Action Dialog SVG Rendering in Hop Web

We investigated the feasibility and architecture of rendering the ContextDialog (the context action / transform picker dialog) content as SVG in Hop Web, comparing it with the existing SVG canvas overlay architecture used for pipelines and workflows (CanvasSvgFacadeImpl, canvas-svg.js).

---

1. Key Takeaways & Why It's Faster and Crisper

1. Eliminating Heavy Server GC Serialization:

   • Current: On Hop Web, ContextDialog.onPaint executes standard Eclipse SWT GC operations (gc.drawImage, gc.drawText, gc.fillRoundRectangle) for ~150 transforms or ~50 actions. Eclipse RAP serializes hundreds of individual 2D canvas draw instructions and raster PNG payloads across the JSON protocol on every search keystroke or redraw.
   • With SVG: The server produces a single vector document (~15–30 KB). On Hop Web, server-side GC canvas painting can be suppressed entirely, reducing canvas GC network traffic to zero.

2. Razor-Sharp Vector Quality on HiDPI / Retina:

   • Current: Icons and text rendered onto an HTML5 <canvas> using 2D bitmap operations appear blurry or fuzzy on 2x/3x Retina screens, mobile devices, and high-DPI displays.
   • With SVG: All icons (embedded via SvgCache / Batik HopSvgGraphics2D) and text labels render as native SVG DOM elements, appearing razor-sharp at any screen DPI or browser zoom level.

3. Instant Client-Side Hover & Tooltips (0ms Latency):

   • Current: On Hop Web, wCanvas.addListener(SWT.MouseMove, ...) is explicitly disabled (if (!EnvironmentUtils.getInstance().isWeb())) because sending cursor moves over the network would saturate the server. Users currently get no visual hover feedback or tooltip descriptions until they click or arrow-key to an item.
   • With SVG: A lightweight client listener hit-tests against the item bounds locally in JavaScript. Hover highlight boxes and the description label update instantly with zero network delay.

4. Simple JavaScript Client (~150 lines):

   • Unlike the pipeline/workflow graph editor (canvas-svg.js, ~2,280 lines), which requires mouse-wheel zoom transforms, pan offsets, rubber-band hop candidate lines, note resize handles, and viewport thumbnails:
   • The ContextDialog client script only needs ~150 lines of JavaScript:
     • Attaches an overlay <div> over wCanvas with pointer-events: none.
     • Injects the SVG.
     • Hit-tests areas on mousemove to move the hover highlight and update the tooltip text.
     • Because pointer-events: none is set on the SVG overlay, clicks, keyboard navigation, and HTML5 drag-and-drop placement (ContextDialogPlacement) continue to work through the canvas without rewriting event logic.

---

2. Architectural Options Evaluated

Option	Approach	Pros	Cons
Option 1: Server SVG via HTTP GET	Mirrors pipeline/workflow pattern: servicehandler=canvasRender + client fetch()	Established pattern in Hop Web	2 round trips on open (RAP response + HTTP fetch)
Option 2: Server SVG Inlined in RemoteObject (Recommended)	Pushes SVG string & areas array directly as properties on RemoteObject hop.ContextDialogSvgRenderer	Single round-trip on open; instant render on first response; no extra HTTP service handler	RAP message payload includes ~20 KB SVG (still far smaller than GC operation stream)
Option 3: Master SVG + Client-side Filter	Sends all items once; client JS hides/reflows items on keystroke	0ms typing response	Duplicates SearchMatcher scoring in JS; logic drift risk
Option 4: Full HTML/CSS Replacement	Replaces ScrolledComposite + Canvas with an HTML widget	Native CSS grid	High regression risk for shared SWT dialog hierarchy and HTML5 DnD

---

3. Recommended Implementation Plan (Option 2)

1. ContextDialogSvgRenderer (in ui):

   • Lays out category headers and action tiles (reusing the desktop grid math).
   • Uses SvgGc (Batik HopSvgGraphics2D) to draw background, category headers, divider lines, vector action icons (from SvgCache), action names (with <text text-anchor="middle">), and selection box.
   • Populates List<AreaOwner> so server-side click hit-testing, arrow-key navigation, and HTML5 DnD continue to work unchanged.

2. ContextDialogSvgFacade & ContextDialogSvgFacadeImpl (in ui / rap / rcp):

   • Abstract facade in ui. Stub/no-op in rcp (desktop continues using SWT GC painting).
   • In rap: registers wCanvas and manages the hop.ContextDialogSvgRenderer RemoteObject.
   • In ContextDialog.onPaint() on Web: skips SWT GC drawing and pushes { svg, areas, contentHeight } to the client.

3. Dedicated RemoteObject Type (hop.ContextDialogSvgRenderer):

   • Kept separate from CanvasGraphRegistry so it never interferes with active pipeline/workflow tabs or zoom state underneath.

4. context-dialog-svg.js (in rap resources, ~150 lines):

   • Registers hop.ContextDialogSvgRenderer type handler in RAP.
   • Injects SVG into an overlay over wCanvas with pointer-events: none.
   • On mousemove, hit-tests against areas locally to update the hover highlight rect and the tooltip text.
   • All clicks and HTML5 drag-and-drop gestures pass directly through to wCanvas and RAP's existing DragSource / onMouseUp handlers.

[mattcasters]

First results are promising. Really fast and crisp rendering. Very fast navigation.