Changes to colour wheel in online

Development
1

Topic for changing color wheel on online! There are a lot of small issues, will try and comment on each below

2

image
image851×691 46.2 KB

Here is the colour picker in libreoffice desktop! For each of RGB and HSB we choose one value to be constant across the entire rectangle, the value of which can be selected by the slider on the side. I found 2 issues with the core implementation:

  1. https://gerrit.libreoffice.org/c/core/+/197342 While moving the mouse the circle indicating the position was not being completely invalidated, leaving pixels of the wrong colour. I believe this may be due to anti-aliasing; increasing the size of the invalidated area seems to fix the issue. (difficulty reproducing; when core is updated, I will upload a photo if I can replicate it again) actually really having difficulty replicating it today? best guess is monitor resolution, which would be fun so gonna test tommorow

  2. https://gerrit.libreoffice.org/c/core/+/197343/1 Redrawing the rect is slow. The resolution is 360 * 452, or 162720 pixels. Whenever the colour slider is draggged, this grid is redrawn multiple times a second. The change I have linked reduces the resolution of the grid while the colour slider is held; without this change, we get 1-2 updates of the grid per second. This also occurs when the increment button is held on the right hand side on the selected attribute.

3

In browsers, we render the grid in core and send the image over to the browser with update actions; this replaces the element with a new element. This causes some issues (mostly addressed in Fix DrawingArea sending messages with an empty id by celestial-starfruit · Pull Request #14009 · CollaboraOnline/online · GitHub):

  1. The old element has it’s id set to ““ when it is removed. This causes any further messages to the server trigger assertion fails. Fixed in pull request.

  2. The position is calculated incorrectly; it uses the position of whatever the mouse is currently over. Fixed by in pull request.

  3. Flickering can occur from th eold image being removed before the new dataurl is parsed into an image. This also causes the dialog to change size. Fixed by https://github.com/celestial-starfruit/online/tree/private/maya/push-wnytxnqpxpkz, but not a particularly nice way to do it.

As @szyklos suggested in the pull request, it would be nicer to simply send across action messages containg just the dataurl. This would prevent issues 1 and 3, and generally should be a nicer way to do it.

4

Regardless of what we do there will be lag; we want to smoothly animate the field as the mouse moves (either moving the circle or sliding the bar), and having to draw it on core is always going to have delay. The other option would be drawing it in the browser; this would require writing a lot of code specific to this particular dialog.

Clearly this could be done on a canvas. I haven’t tried it yet, would require a lot of dedicated code + may have performance issues; if we get lag on desktop doing the same thing in javascript may also be slow.

Alternatively a lot of this could be done with CSS; I’ve written some quick html files.

<html>
<style>
#a {
  background: linear-gradient(to top,black, red);
}

#b {
  background: linear-gradient(to right, black, blue);
  mix-blend-mode: lighten;
}

#c {
  background-color: lime;
  mix-blend-mode: lighten;
  opacity: 0%;
}

div {
  width: 100%;
  height: 100%;
}
</style>

<div id="a">
  <div id="b">
    <div id="c">
      <br><br><br>
    </div>
  </div>
</div>
</html>

For RGB there is a very simple implementation. CSS has no HSB support, but does end up supporting HSL to a fairly high degree. For HSL we may need to send the original image over, then apply effects to it later. “filter: saturate”, “filter: brightness” and “filter: hue-rotate” may seem like they fit well, but they don’t actually work in the HSL colour space (e.g. saturate() - CSS | MDN ); we end up with a different coloured rectangle as we would have got in libreoffice desktop.

(Just remembered; maybe using hue/saturation/luminosity blend mode would work better?)

We also can’t directly get the colour under the mouse pointer; currently we get the coordinates of the mouse over the rect, then send those to CORE; using a canvas would solve this though.

5

Thanks @celestial-starfruit for the investigation! It’s great to see that browsers already support so much, but the missing advanced features — especially CMYK support and other professional-grade controls found in current dialogs — are still significant blockers for office document users. These capabilities are essential for users who need precise color management and print fidelity.

This is a nice post that we can keep for discussion around color pickers and possible more future stuff rendered on the browser side.