fbGFX: BUG in Paint statement

General FreeBASIC programming questions.
counting_pine
Site Admin
Posts: 6174
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: fbGFX: BUG in Paint statement

Postby counting_pine » Apr 07, 2019 21:39

dodicat wrote:using opaqueness:
It only takes one pixel overlap in a perimeter to leak, because this pixel will be a different colour
Using line()-(),b overlaps at each corner.

Nice discovery, dodicat!
I've put a note about this in the bug report: #896

Unfortunately fixing the box drawing to prevent this double-blending would be painful to do.. I just researched into how QB draws boxes in viewtopic.php?f=7&t=27540, and the corner pixels are genuinely drawn twice (or up to twice, depending on the bits of the 'style' parameter). So it would be hard to fix this in a QB-compatible way.
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 9:16

In #896, MrSwiss wrote:This fact should at least be documented, on the LINE doc-page, of the FB-reference.

To begin, see proposal for note to be added at the description end of PAINT keyword:
Note: If the border is drawn with a transparent color and some pixels overlap, it causes a multiple-blending of color on these pixels and the resulting color of blending is not the one expected on these singular points. This can lead to the paint color flowing through these pixels (except for corner pixels).
The Line keyword, used in rectangular box mode, induces superimposed pixels on corners only. But chained uses of Line and even the Circle keyword usually induce overlapping pixel at locations which cause overflow the fill by Paint.
Last edited by fxm on Apr 09, 2019 13:14, edited 1 time in total.
counting_pine
Site Admin
Posts: 6174
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: fbGFX: BUG in Paint statement

Postby counting_pine » Apr 09, 2019 12:57

I don't know..
On the one hand, the cause for this problem was not obvious, and baffled multiple people.
On the other hand, it feels like a lot of text just to say, in effect, "warning: blended borders will be blended".

Really, the problem here is that boxes are drawn twice at the corners, and that should be considered a bug with Line, rather than a "feature" to be worked around.
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 13:21

There is an easy workaround for boxes (do not take the box corner as reference for the border color), but not for circles where overlapping pixels are aligned with other pixels.
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 13:26

I can reduced my proposed note (in PAINT) to its first part only (which is purely factual):
Note: If the border is drawn with a transparent color and some pixels overlap, it causes a multiple-blending of color on these pixels and the resulting color of blending is not the one expected on these singular points. This can lead to the paint color flowing through these pixels.

... but not adding anything in the documentation avoids self-polling for "beta" users (and it allows me to get some additional time to do other things on other sites)!
MrSwiss
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: fbGFX: BUG in Paint statement

Postby MrSwiss » Apr 09, 2019 14:28

fxm wrote:Note: If the border is drawn with a transparent color and some pixels overlap, it causes a multiple-blending of color on these pixels and the resulting color of blending is not the one expected on these singular points.
Above sentence is okay, but I don't really like the second sentence.
MrSwiss - proposal - wrote:Those off color pixels (one does it) will lead to a 'leak-pixel', through which fill color escapes the bordering line!


This part of the proposal, should be made in the LINE part of doc. (as amended):
MrSwiss - proposal - wrote:But chained uses of Line usually induce (one or more) overlapping pixel(s) at locations which cause a overflow of Paint's fill color.
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 14:53

Maybe just add clarification:
MrSwiss wrote:This part of the proposal, should be made in the LINE part of doc. (as amended):
MrSwiss - proposal - wrote:But chained uses of Line usually induce (one or more) overlapping pixel(s) at locations which may cause a overflow of Paint's fill color if a transparent color is used for the border.

+ similar remark in CIRCLE page.
MrSwiss
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: fbGFX: BUG in Paint statement

Postby MrSwiss » Apr 09, 2019 15:01

fxm wrote:Maybe just add clarification:
MrSwiss wrote:This part of the proposal, should be made in the LINE part of doc. (as amended):
MrSwiss - proposal - wrote:But chained uses of Line usually induce (one or more) overlapping pixel(s) at locations which will cause a overflow of Paint's fill color if a transparent color is used for the border.

+ similar remark in CIRCLE page.

may <-- not acceptable (maybe yes, maybe no), looking like "speculation" more than anything
we are talking about a fact (especially with your added specifiers)
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 15:58

Synthesis of proposed additions in the "Description" section of the documentation pages:

- On the PAINT page:
Note: If the border is drawn with a transparent color and some pixels overlap, it causes a multiple-blending of color on these pixels and the resulting color of blending is not the one expected on these singular points. Those off color pixels (one does it) will lead to a 'leak-pixel', through which fill color escapes the bordering line!

- 0n the LINE page:
Note: Chained uses of Line usually induce (one or more) overlapping pixel(s) at locations which will cause a overflow of Paint's fill color if a transparent color is used for the border.

- On the CIRCLE page:
Note: Circle usually induces (one or more) overlapping pixel(s) at locations which will cause a overflow of Paint's fill color if a transparent color is used for the border.
MrSwiss
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: fbGFX: BUG in Paint statement

Postby MrSwiss » Apr 09, 2019 16:30

This is looking good. After updating of the doc's, I'll close the issue at Source Forge.
(A probable fix on fbGFX seems unlikely, as pointed out by counting_pine.)

With the updates on doc's, it's far less likely, that somebody might end up with troubles.
(If and only if, people in general learn, to consult doc, before writing '...' posts!)
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 19:25

Done:
- KeyPgPaint → fxm [Added note about eventual bad filling behavior when using a transparent color for the border]
- KeyPgCircle → fxm [Added note about bad filling behavior by Paint when drawing a border with a transparent color]
- KeyPgLinegraphics → fxm [Added note about bad filling behavior by Paint when drawing a border with a transparent color]
MrSwiss
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: fbGFX: BUG in Paint statement

Postby MrSwiss » Apr 09, 2019 20:06

Done:
Posted on Source Forge: message that bug-report #896, can be declared "closed".
paul doe
Posts: 986
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: fbGFX: BUG in Paint statement

Postby paul doe » Apr 09, 2019 20:32

counting_pine wrote:...
Really, the problem here is that boxes are drawn twice at the corners, and that should be considered a bug with Line, rather than a "feature" to be worked around.

Wouldn't it be possible to specify a 'tolerance' value when filling? That way, filling would work pretty much like programs such as GIMP: instead of matching the color exactly, it is matched within the specified tolerance value...
fxm
Posts: 9316
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: fbGFX: BUG in Paint statement

Postby fxm » Apr 09, 2019 20:51

Referring to the following example:

Code: Select all

Const As UShort wid = 1024, hei = 768, cd = 32, pg = 2, sflg = 64

ScreenRes(wid, hei, cd, pg, sflg)       ' sflg = GFX_ALPHA_PRIMITIVES
Width wid \ 8, hei \ 16
Color(&hFF000000, &hFFFFFFFF) : Cls     ' black (fg) on white (bg)

Line (100, 100)-(wid-101, hei-101), &hBFFF0000, B   ' 25% transparent border = leak

Locate 2
Print " Color of corner pixels of box: "; Hex(Point(100,100)) '' C3FF1010
Print " Color of other pixels of box : "; Hex(Point(100,101)) '' CFFF4040

Paint(101, 101), &h3fFFFF00, Point(100,101) '' (avoiding the corners of the box as reference for border color)

Sleep

Code: Select all

Color of corner pixels of box: C3FF1010
Color of other pixels of box : CFFF4040
dodicat
Posts: 6030
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: fbGFX: BUG in Paint statement

Postby dodicat » Apr 10, 2019 12:41

Here is the border colour automated for a black background.
I have a function for any colour background, but it is sometimes one byte off either the red,green,blue or alpha.
So I am still working on that.
NOTE the 32 bit and 64 bit are different and are separated by the criterion size of integer.( I keep forgetting #if 32 bits or #if 64 bits macros, and they are hard to find and remember)
Press space to refresh, esc to end.

Code: Select all

 
Screen 19,32,,64

Function BorderColour(c As Ulong) As Ulong
    Dim As Ubyte alf=Cast(Ubyte Ptr,@c)[3]
    Dim As Long rd=((Cast(Ubyte Ptr,@c)[2])*alf)
    Dim As Long gr=((Cast(Ubyte Ptr,@c)[1])*alf)
    Dim As Long bl=((Cast(Ubyte Ptr,@c)[0])*alf)
    If Sizeof(Integer)=4 Then  '32 bits
        Dim As Uinteger b
        Screencontrol 13,,b
        Dim As Ubyte  newalf=(((Cast(Ubyte Ptr,@c)[3])*alf)+(Cast(Ubyte Ptr,@b)[3]*(255-alf))) Shr 8 +1
        Return Rgba((rd Shr 8 ),(gr Shr 8 ),(bl Shr 8 ),newalf)
    Else                        '64 bits
        Return Rgba((rd Shr 8 ),(gr Shr 8 ),(bl Shr 8 ),alf)
    End If
End Function

#define range(f,l) Int(Rnd*(((l)+1)-(f))+(f))
Dim As Long x1,y1,x2,y2
Dim As Ubyte rd,gr,bl,alf
Do
    x1=range(20,300)
    y1=range(30,200)
    x2=range(500,799)
    y2=range(400,599)
    rd=Rnd*255
    gr=Rnd*255
    bl=Rnd*255
    alf=50+Rnd*200
   
    Dim As Ulong box=Rgba(rd,gr,bl,alf)
    Cls
    Line(x1,y1)-(x2,y2),box,b
   
    Dim As Ulong p=(Point(x1+2,y1))  'for comparison
    Dim As Ulong b= BorderColour(box)
   
    Draw String(360,300),"HELLO"
    Paint(x1+5,y1+5),box,b 'just inside the box
   
    Print "rgba(";rd;",";gr;",";bl;",";alf;")","box colour"
    Print "rgba("; Cast(Ubyte Ptr,@p)[2];",";Cast(Ubyte Ptr,@p)[1];",";Cast(Ubyte Ptr,@p)[0];",";Cast(Ubyte Ptr,@p)[3];")","from point"
    Print "rgba("; Cast(Ubyte Ptr,@b)[2];",";Cast(Ubyte Ptr,@b)[1];",";Cast(Ubyte Ptr,@b)[0];",";Cast(Ubyte Ptr,@b)[3];")","from function"
   
    Sleep
   
Loop Until Multikey(1)

Sleep

Return to “General”

Who is online

Users browsing this forum: No registered users and 2 guests