This is a very inefficient solution.
The drawing unit takes an X, Y, and color, and then draws a 30-pixel line at that point. The first two units in the top row read in the number of pixels to draw and then slice that up, returning both the X position to start drawing and a flag saying whether or not to move on to the next line. If the current slab spans more than one line, the units will produce more than one of these pairs before reading from the input again. For example, for the inputs [36, 26, 23, 34] and a row length of 30, they’ll send out (0, wrap) and draw 30 of 36 pixels, (0, don’t wrap) and draw the last 6, (6, wrap) and draw 24 of 26 pixels, (0, don’t wrap) and draw the last 2, (2, don’t wrap) and draw 23 pixels, (25, wrap) and draw 5 of 34 pixels, and (0, don’t wrap) and draw the last 29.
The reason it draws 30-pixel lines is that I found it too complicated for the mechanism to also send out a specific width to draw. Since we draw from left to right, the spillover pixels would just be overwritten by the next slab, so there’s no harm in setting them to something else before we draw the actual correct colors onto them. (Unless the image data doesn’t span the whole bitmap, but it always does.)