gfx_ScreenCopyPaste broken on uLCD28PT-I with PmmC R28 ?

[sinus]

It seems that the gfx_ScreenCopyPaste command won't work any more on the uLCD-28PT_GFX2 (the newer one, "S I R20" on the warranty label) with the newest PmmC (uLCD-28PT-I-GFX-R28.PmmC). The function now just doesn't do anything.

I was wondering if I made any mistake, but on a uLCD-32PT with the R28 PmmC the same 4dg programm works flawless.

Any hints ?

[meldavia]

Thanks for the report,

there does seem to be a problem, we are working on it now.
Will keep you posted

[guru_florida]

Any update on this? I want to use this function to speed up my code. Kind of slow updates otherwise.

[guru_florida]

I just checked the web site and downloaded the recent version which has the fix. Thank you.
This function is slower than using the rectangle fill and lines and setpixel. I am suprised. I would have thought this copypaste would be super fast, basically like an erase cycle.

[ESPsupport]

Unfortunately the only way this can be done is for the Picaso chip to read everything off the display and rewrite it at its new location, a byte at a time, setting the read and write address for each byte. This is because the controller within the display does not support separate read and write addresses.

This means copy paste is very slow, many times slower than either reading the display or writing the display.

[guru_florida]

I see. I figured it was there to be efficient. As in a single mnemonic that copied video ram from one location to another - a bitblt. That's too bad, would be a nice feature.
It's drawing 2D grids. I did a bit of shuffling of gfx commands and I have it refreshing without flicker at all - very fast. (a lot of hlines, vlines), no global erase.
C

[EMHmark7]

Hi,
I am on mLCD43PT, Picaso, v 3.4.
It seems that gfx_ScreenCopyPaste(xL,yL,xL,yL+12,wtL[5]-2,(NBlinesL[5]-1)*12);
has a bug.

If I do gfx_ScreenCopyPaste(xL,yL+12,xL,yL,wtL[5]-2,(NBlinesL[5]-1)*12);
it scroll the main area up (a pick list)

But just putting the +12 at the destination side,
it does not copy down the area, it takes the first line of text at the top (about 12 pixels high)
and duplicate at every textline billow all the way down to the specified area.

Heard about something for that, a bug fix, or I missed something?

Thanks,

[Atilla]

Try Version 3.5 PmmC, Downloads section:

http://www.4dsystems.com.au/product/1/11/4D_Intelligent_Display_Modules/uLCD_43/

[EMHmark7]

Thanks,

Where do we find the procedure for firmware update?
...
Ok, I run the PMMC Loader in Tools menu.
It displays well the version on the device.
But the bug remains.

[ESPsupport]

Hmm, looks like a but in screecopypaste that has always been there.

Give us a couple of days to investigate

[EMHmark7]

Will be nice. For now, I can manage to redraw all the things the more CPU demanding way.
But it is still necessary if we want to get rid of the enoying flicker if we redraw a scrolled picklist.

[EMHmark7]

Hi,

Seems the new version (v3.6) of function gfx_ScreenCopyPaste() is still bugged.

Unless I miss something in my code:

gfx_ScreenCopyPaste(xL,yL,xL,yL+12,wtL[L]-2,(NBlinesL[L]-1)*12+1);

It seems that the function takes the destination Y as the origin Y,
so it takes into account things that are one text line billow,
leaving alone the first line,
and at the end, pasting one line high too far bellow.

In my case, copying from yL to yL+12 (so shifting down)
Both behaviors seem to be consistant with my hypothesis.

Marc

[ESPsupport]

Hmm, seems to work fine for me...

var xL, yL ;
gfx_Rectangle(0,0,21,21,RED) ;
gfx_Rectangle(0,30,21,51,LIME) ;
gfx_RectangleFilled(1,1,20,20,BLUE) ;
xL := 1 ;
yL := 1 ;
gfx_ScreenCopyPaste(xL,yL,xL,yL+30, 20, 20);

copies the Blue filled rectangle from the RED box to the LIME box, without any errors.

If you still have problems, can you give me a simple example?

[EMHmark7]

Ya, sorry.
It works now.
It was related to the equivalent code needed to simulate the scroll by printintg the text.
the YL var used needed an yL+=12 that started before the code block and had to be removed as well.
Of course, even when the function bug existed, the function was working well in the other direction (from lower to upper screen zone) so this code was not present in that direction because it was using the gfx_ScreenCopyPaste() function.

End result: You helped me make it work!!! Great! Isn't it!
Thanks!
At the end of the day (littrally timewise, you answer so shortly after questions asked, you are not so far after all!)

Marc