Well, I see three usecases for the selection&#39;s extents:<br>1) Using a selection for filtering/composing another paint device. In such a case we need to know &quot;the area of non-transparent (non-black) pixels inside the selection&quot;.<br>
In this usecase default bounds are mandatory. We just get a selectedRect() (corrected by KisDefaultBounds) and process the resulting area.<br><br>2) Filtering/modifying a single selection. In this case we need to know &quot;the area of non-default tiles&quot; that we need to process. The processing is done in two stages: 1) modifying non-default tiles (regions, rects, whatever granularity you want); 2) processing the default pixel of the selection. Here we should be very careful, because we cannot use the exactBounds() area for processing. Otherwise, after we change the default pixel of the selection, the pieces of the non-default-tiles containing default-areas (region = extent() - exactBounds()) will *not* change their state. So they will be left unprocessed.<br>
<br>3) Composition of two selections. This case resembles the second one. We need to know &quot;non-default areas&quot;. The processing is done in two stages: 1) modifying the union of two regions of non-default tiles; 2) modifying the default pixel. And we can&#39;t use exact bounds as well.<br>
<br clear="all">So currently, we do already have the implementation of all the necessary methods for all the three usecases. The only trouble we have, we need to ensure somehow (by API, maybe), that the user will not forget to process the default pixel of the device in the cases 2 and 3. <br>
<br><br>-- <br>Dmitry Kazakov<br>