Next steps for removing selection gap painting

57 views
Skip to first unread message

Chris Harrelson

unread,
Jun 1, 2015, 3:23:12 PM6/1/15
to blink-dev
TL;DR:

After collecting lots of feedback on this list and from others internal to Google, the paint team plans to move forward with removing selection gap painting (tracked in crbug.com/471908). Before doing so, we will add support for representing newlines in selection, in order to address that key missing use case (tracked in crbug.com/474759).

Details:

Use cases: discussion revealed one important use case that would be broken if selection gap painting were removed: representing newlines or tabs between regions of selected content. We have a plan to implement support for that use case in a clean way, and will block selection gap removal on implementing it. The UX for this use case will be the same as that in Google Docs.

Reasons for removal:

* Significant complexity. In particular, selection gap painting causes a separate tree walk during painting that collects these gaps, plus trying to compute exclusion rects for cases such as floating children. Almost all other painting code does not do this.

* Ugly UX in the presence of irregular content. Webpages have complicated and irregular layout. This very often breaks the UX goal of selection gaps being a nice rectangle, and leads to a jumble of them that map to the internals of the web page's box structure, but not really to what the user expects.

* Bugs. The tree walk described above has several known bugs that cause double-painting, and that are not simple to fix.

* Performance. The above tree walk has worse performance than can be achieved by integrating with the main paint tree walk.

On Thu, Apr 2, 2015 at 2:47 AM, Daniel Bratell <bra...@opera.com> wrote:
On Wed, 01 Apr 2015 05:56:53 +0200, Shezan Baig <shezb...@gmail.com> wrote:

The other case where I think selection gaps are useful is when selecting table cells, especially when editing.  Without selection gaps, its difficult to tell the difference between (a) selection that ends at the last character in the cell, and (b) selection that extends into the next cell.

I approve of removing the gap painter, but I think it's in place to check the selection rendering of thing like "trailing whitespace" and empty lines (<br><br><br>) because those things are tricky and they might have been assisted by gap rendering (not that I know exactly how it works).

The selection rendering is crucial for editing and when you edit a document such selections appear all the time as part of the work.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yoichi Osato

unread,
Jun 1, 2015, 9:46:19 PM6/1/15
to Chris Harrelson, blink-dev
I don't understand 'selection gap' is.
Do you have screenshots of before/after your refactoring?

2015年6月2日(火) 4:23 Chris Harrelson <chri...@chromium.org>:

Philip Rogers

unread,
Jun 1, 2015, 9:51:33 PM6/1/15
to Yoichi Osato, Chris Harrelson, blink-dev
Selection gaps are the areas between text such as boxes. There are some screenshots in the original discussion: https://groups.google.com/a/chromium.org/d/msg/blink-dev/qSC0Mrh_GnA/vwq_gDnz66gJ
Reply all
Reply to author
Forward
0 new messages