2014-05-22 03:29 PM
Hi,
I just spent a couple of days integrating STemWin in a starter project and got that to work rather nicely. Now I am toying around with it so see if it can do all the things I need for my display project. In the process I noticed a vertical black line on the display that appears to be an artifact of the drawing algorithm (GUI_AA_DrawArc()). I am using black background and white foreground. It looks like a single pixel line and shows only in the upper half of the display, the lower half is fine. That would be at 90 degrees for the arc. Here is the drawing code: -----GUI_AA_SetFactor
(
3
)
;
GUI_AA_EnableHiRes
()
;
GUI_SetPenSize
(
5
)
;
GUI_AA_DrawArc
(
360
,
360
,
344
,
0
,
10
,
350
)
;
GUI_SetPenSize
(
40
)
;
GUI_AA_DrawArc
(
360
,
360
,
260
,
0
,
210
,
330
)
;
GUI_RECT
clip
=
{
80
,
10
,
160
,
150
}
;
GUI_SetClipRect
(
&
clip
)
;
GUI_AA_DrawArc
(
360
,
360
,
260
,
0
,
40
,
150
)
;
GUI_SetClipRect
(
NULL
)
;
----- The artifact shows up in both the first and the third arc (the one in the clip region) at the same x-location. Has anyone seen something like this before. Could there be a setup problem (though I have no idea where that might be) or might this be a bug in the drawing algorithm? #stemwin-drawing2014-06-09 08:05 AM
Hi,
We have tried to reproduce your issue, as described below:2014-06-09 03:56 PM
Hi,
thanks for checking on this. I'll have another look at my driver code and the hardware though I strongly doubt that the problem is there. I can draw fine in all colors in the area in question. For example I placed bitmap images there and they draw fine. I also can draw other figures there (filled circles for example or text) and they draw fine as well. It's just arcs that do that. Also it is not the entire column of pixels that does not draw. It is just from the center up. Perhaps it has something to do with a particular antialiasing setting. I'll try different settings. This might take a few days though. I just received new hardware that I had to solder up. I have to get that to work first. Did you have a look at the attached picture? Thanks2014-06-10 09:50 AM
Here is another quick update.
I checked the driver code again. There is really nothing that can go wrong (I know, famous last words...). Our LCD is using the ILI9341 controller chip. There is a write routine for data and one for the register. All they do is to write unmodified data to the appropriate address, like that:static
void
lcdWriteData
(
U16
value
)
{
*
lcdData
=
value
;
}
The addresses are mapped such that the control pin ends up in the correct state for writing to the control register or to the data register. This is also used to initialize the LCD and to do all other operations, such as erasing, drawing bitmaps and what not. I can't see how this can all work, but then fail in just the specific way I experience. Also, I tried to move the center of the arc away from the center of the display and the artifact follows the new center position. If the problem was linked to a specific address or column, the artifact would stay in place. I don't know what it is, but the problem appears to be clearly linked to the rendering code.
Thanks again for paying attention to this problem.2014-07-16 11:23 AM
Hmmm, perhaps I should not have thanked you so quickly for paying attention to this problem. Clearly no attention has been paid to it in over a month.
I had to work on other projects, but I am coming back to this now and I have to make a decision what library to use going forward. Seeing that my issue is not resolved and you seem to think there is no problem on your end, tells me this will never be addressed. Not a good thing to base may future projects on. Regards2014-07-16 12:31 PM
Clearly no attention has been paid to it in over a month.
This is a user forum, the attention paid to your problem is commensurate with what you paid for support, and your level of participation. If you think there is a problem with the Segger software please try discussing it with them, on their forum.