<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi Hilaire, Your code is perfectly fine. The origin of the problem is that VectorEngine draws pixels differently from BitBlt.. In particular, if a morph that #requiresVectorCanvas like your DecoratedPane is made submorph of another that doesn't #requiresVectorCanvas (and uses BitBlt by default), then we can't guarantee that they fill exactly the same pixels, even if they request to fill the same rectangle. The whole problem disappears if the whole morph uses only VectorCanvas. You can try this by slightly zooming it. Still, using BitBlt when possible has a significant performance advantage, so we need another solution. The easiest solution I see, if acceptable to you, is to remove the call to super in DecoratedPane>>#drawOn:. Then you'll need to adjust the color of the owner LayoutMorph. If you absolutely need the LayoutMorph to be gray, then what would be required is to add anothe morph between them, to draw the box using BitBlt. It could make layout a bit more complicated, so I think my previous suggestion is better. Hope this helps. On 7/2/2023 2:56 PM, Hilaire Fernandes via Cuis-dev wrote: <blockquote cite="mid:acf61903-6b33-eccd-e2a3-742df64ba236@free.fr" type="cite"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> Hi, In my bread crump morph below you can observe the views under the button nav bar are shifted one pixel to the right and the bottom directions: ... I need to explain a bit the logic of the GUI tool. The data can be viewed or edited. In the screenshot it is in edit mode, to got back to view mode, click on the button 'Foron', it is the named of the edited object (a School instance). When the tool is in editor mode, the decorated morph are layout with a one pixel gap as I explained above. Between the 4 decorated morphs (Information, Time slots, etc.) there is also this unexpected 1 pixel gap. It produces glitch in the background when the whole morph is dragged around. When in viewer mode, although the same kind of decorated morphs are used, there is no such visual artifact. For me code seems all good. In case one want to take a look I have an image: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.dropbox.com/scl/fi/islj0kloljw040wvbr3f2/dynabook.zip?rlkey=kuoxfzjobr3jesjdngd6k1ype&dl=0">https://www.dropbox.com/scl/fi/islj0kloljw040wvbr3f2/dynabook.zip?rlkey=kuoxfzjobr3jesjdngd6k1ype&dl=0</a> Thanks Hilaire <pre class="moz-signature" cols="72">-- GNU Dr. Geo <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://drgeo.eu">http://drgeo.eu</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://blog.drgeo.eu">http://blog.drgeo.eu</a></pre> </blockquote> <pre class="moz-signature" cols="72">-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich</pre> </body> </html>