In the bug report is a patch.

http://bugs.freepascal.org/view.php?id=16682

Regards,
- Graeme -

I don't think this is a bug. It's usual that Right/Bottom denotes one pixel off intended rectangle. Think in terms of floating point: 1 = 1.0 means left side of the pixel. And 1.5 would mean center of pixel. So in THAT case, difference between left-most and right-most pixels are 2.5-1.5=1.0. On the other hand, width of rectangle is still 2.0 -> one between 1.0 and 2.0, and the other between 2.0 and 3.0.

Huh, too much text for such simple math :-)

Rect and Bounds work mathematically.
A pixel has a size of 1x1 and Left, Top is the left, top edge of a pixel.

Mattias

It's not a bug. Plz withdraw (0..9)(1..10?????)

Op 2010-06-09 09:40, Mattias Gaertner het geskryf:

Rect and Bounds work mathematically. A pixel has a size of 1x1 and Left, Top is the left, top edge of a pixel.

That is not mentioned anywhere in the docs so how are we supposed to know what Bounds() is supposed to be used for. Also 99% of cases where TRect is used, it's in a graphical aspect. ClientRect, WindowRect, GetClientBounds, TextRect... and a million others. All related to graphics (and pixels on a screen)

Maybe we then need a GraphicalBounds() and MathBounds() to distinguish between the two, and remove Bounds() completely. Bounds() on it's own is just to vague, and more often than not, its calculation of Right and Bottom is incorrect based on (graphical) usage.

Regards,
- Graeme -

I agree, such basics should be explained in a tutorial and the docs of classes and types.

Also 99% of cases where TRect is used, it's in a graphical aspect. ClientRect, WindowRect, GetClientBounds, TextRect... and a million others. All related to graphics (and pixels on a screen)

Yes, and afaik most use mathematical width/height for the simple reason they "add up" (commutative and associative).

Maybe we then need a GraphicalBounds() and MathBounds() to distinguish between the two, and remove Bounds() completely. Bounds() on it's own is just to vague, and more often than not, its calculation of Right and Bottom is incorrect based on (graphical) usage.

Bounds is used a lot in Delphi and LCL applications.

Mattias

Op 2010-06-09 10:24, Mattias Gaertner het geskryf:

Bounds is used a lot in Delphi and LCL applications.

So for "delphi compatibility" we now need to duplicate Delphi bugs in FPC too? FPC DELPHI.

This is just crazy! Where are we going to draw the line with Delphi compatibility and actually implement something in FPC that is correct, not vague and on ALL platforms not just freaking Windows (+ Delphi). Yes Delphi is important (I get that), but so is FPC on other platforms. FPC is not "Delphi for Linux", or "Delphi for Mac" etc. That's Embarcadero's domain.

In the last 6 months I found so many bugs in FPC, but every single one was shot down and said: It's Delphi compatible. End of discussion! Well, Delphi doesn't exist on Linux, FreeBSD, Solaris, WinCE, Embedded Linux, Android, iPhone, Mac, Haiku etc.. All platforms FPC supports too.

I give up... Lets hope Embarcadero brings out an excellent Delphi x-platform compiler, then I can switch to Delphi and be done with it. Clearly that's the goal of FPC - drive developers back to Delphi. You guys should charge Embarcadero for your services.

Regards,
- Graeme -

As explained, it is not a bug. Classes does not aim on gui only development so the behaviour is logical. If you don't like it, create a fpGuiBounds function.

Op 2010-06-09 10:46, Florian Klaempfl het geskryf:

As explained, it is not a bug. Classes does not aim on gui only development so the behaviour is logical.

I see Jonas marked it as a Documentation bug so that it's usage can clearly be defined for math use only. I still think it should then be moved to the Math uni, but that is not "delphi compatible" - though it would be a lot less ambiguous there.

Regards,
- Graeme -

Why? I could imagine to add a PixelBounds function to a newly PixelGraphics unit. Only pixel graphics might need a different interpretation of bounds, the current behaviour is perfectly valid for any other uses.

Op 2010-06-09 11:02, Florian Klaempfl het geskryf:

interpretation of bounds, the current behaviour is perfectly valid for any other uses.

Not as I see it, and described in the bug report. Think of the pixel screen/grid like the grid of a spreadsheet (as as a magnified look of the top corner of your screen)

0 1
+---+---+---
0 | x | |
+-+-+---+---
1 | | |
+-+-+---+---
2 | | |
+-+-+---+---

x is at (0,0). A pixel is always 1x1, you don't get smaller (we are not using sub-pixels like on LCD screens, because they don't apply to all screens).

So with that example, Width = 1 pixel and Height = 1 pixel. In the case of Classes.Bounds() the Right and Bottom values are (1,1) which looking at the above image will be wrong, the pixel only covers one block, so in a screen/pixel environment, Right, Bottom is also (0,0), the same as Top/Left.

0 1
+---+---+---
0 | x | x |
+-+-+---+---
1 | x | x |
+-+-+---+---
2 | | |
+-+-+---+---

In this example we have a rectangle. Top/Left = (0,0) and Bottom/Right = (1,1). This means Width = 2 pixels and Height = 2 pixels. Clearly visible in the image above.

But if we call Classes.Bounds(0,0,2,2) it reports Bottom/Right as (2,2) which is wrong (again looking at the image above as reference). This is my point. Bounds() cannot be used in this case in a graphical environment.

The reason I don't use a grid layout as below (as Mattias hinted at), is because if the mouse is over the x, the OS (graphics system) reports its position as (0,0). You don't have to have the mouse pointer over the cross-section lines (0,0) as indicated in the image below. The whole square containing the x is referenced as (0,0), hence my grid layout as show in the images above. The same grid layout as used in TStringGrid or a spreadsheet etc.

0 1
0 +---+---+---
| x | |
1 +-+-+---+---
| | |
2 +-+-+---+---
| | |
3 +-+-+---+---

Regards,
- Graeme -

Pixel usage.

Actually, everything works fine here :-) You just have to change your point of view regarding coordinates. You assume that integer coordinates represent center of pixel, but they actually represent top-left corner of pixel. In other words, think of coordinate 0 as 0.0, not 0.5 and the math will work perfectly fine :-)

Op 2010-06-09 12:08, Aleksa Todorovic het geskryf:

point of view regarding coordinates. You assume that integer coordinates represent center of pixel, but they actually represent top-left corner of pixel. In other words, think of coordinate 0 as 0.0, not 0.5 and the math will work perfectly fine :-)

An if you read the rest of my reply, you would have seen the reason why I use that coordinate system, instead of the intersecting lines (and rather like a spreadsheet or TStringGrid). The way the OS graphics system works (at least for GDI & X11) - confirms my thinking. If you have a 1x1 pixel at (0,0) on the screen, the mouse cursor can be anywhere inside the 1x1 rectangle (rectangle with the x in image below), and the OS reports it as location (0,0). My coordinate system reflects this behaviour. If only the top/left corner (intersecting lines) was (0,0), then my mouse cursor would also have to be in the top/left corner before the OS reports (0,0) - which it doesn't.

0 1
+---+---+---
0 | x | |
+-+-+---+---
1 | | |
+-+-+---+---
2 | | |
+-+-+---+---

Regards,
- Graeme -

Let's imagine (it doesn't have to be true) that OS calculates mouse coordinates as floating point values. In that case your mouse coordinates are in the range (0.0 - 0.999999), but OS reports it as (0, 0), which means that OS internally calls Trunc. So, you can think of coordinates as Trunc-ed (not Round-ed!) version of real coordinates.

Zitat von Aleksa Todorovic :

It's correct that a pixel is an area, usually of size 1x1. So when you say it is at 0,0, then you are really saying: the left,top corner of the pixel is at 0,0 and the right, bottom corner is at 1,1. With the Bounds function:

Bounds(0,0,1,1)

Math: Right-Left=Width
Graeme: Right-Left=Width-1

For example: Let's say you have a position 3.
The math says it is the left edge of pixel 3 (usually the fourth pixel). Graeme says: If it is a Left, then it is the left edge of pixel 3, if it is a Right then it is the right edge of pixel 3.

Graeme's definition is useful for drawing a pixel based rectangle (with line width of 1).
When computing with coordinates the math definition is easier as you don't have to know if it is a left or right.

That's only correct for a line width of 1.
The rectangle has a line width of 1 pixel, 0.5 pixel around the four x. This means the rectangle has Width=1 and Height=1, but including the thickness of the line the total rectangle has Width=2 and Height=2. The difference can be seen when using libraries that supports sub pixel rendering like aggpas.

> But if we call Classes.Bounds(0,0,2,2) it reports Bottom/Right as (2,2) > which is wrong (again looking at the image above as reference). This is my > point. Bounds() cannot be used in this case in a graphical environment.

Yes, it can. If you want the rectangle including the line width of 1, you must add 1. If you use a line width of 5 you must add 5. Maybe you want a Bounds function like this:

function RectangleHull(Left, Top, Width, Height: integer; LineWidth:
integer = 1): TRect;

The math works with 0.0, 0.5 and 0.9. But if you don't use sub pixel rendering you won't see the difference.

[...]

Mattias

[...]
I think you are wrong, TRect has been defined in order to communicate rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...): http://msdn.microsoft.com/en-us/library/aa932720.aspx "
When filling the specified rectangle, FillRect does not include the rectangle's right and bottom sides.
GDI fills a rectangle up to, but not including, the right column and bottom row, regardless of the current mapping mode.
"
http://msdn.microsoft.com/en-us/library/aa932835(v=MSDN.10).aspx "
The region will be exclusive of the bottom and right edges. "

Because of the ambiguity MSEgui uses solely the "rectty" type:
"
 rectty = record
           case integer of
            0: (x,y,cx,cy: integer);
            1: (pos: pointty; size: sizety);
          end;
"

Martin

Op 2010-06-09 14:32, Martin Schreiber het geskryf:

TRect has been defined in order to communicate rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...):

And X11 (XLib) was intelligent enough to foresee the ambiguity and use X, Y, Width, Height in all drawing API's instead of Top,Left,Right,Bottom. We all know Microsoft is just as capable as everybody else to create sh*t software or APIs.

Now I can argue once again that FPC is supposed to be a x-platform product, hence it should not JUST follow Microsoft to every single word, but also take other platforms (8+ at last count) into consideration. But then somebody would throw the "not delphi compatible" seem to be stuck in a endless loop: I find a issue, report it, get told it's not delphi compatible, everybody ignores issue. Repeat.

I should also point out that you can (and least I know this is true in Xlib) adjust the pen cap attributes, which changes the behaviour you mentioned. At which point it can include the Right/Bottom pixels in rectangle, line drawing etc.

Because of the ambiguity MSEgui uses solely the "rectty" type:

And fpGUI has TfpgRect since the start. I just seem to think it's rather stupid that everybody needs to implement their own types, functions, classes because the default behaviour of FPC is idiotic and doesn't apply to non-Windows platforms. From the start my goal with fpGUI was to use as much as possible of what is includes by FPC as default (so I don't have to re-invent the wheel) - this means functions, classes, packages etc. But lately I think that is simply a pipe-dream, because everything I want to do or change, seems to be "not delphi compatible" and such changes are NOT allowed in FPC.

  TfpgRect = object  // not class for static allocations
    Top: TfpgCoord;
    Left: TfpgCoord;
    Width: TfpgCoord;
    Height: TfpgCoord;
    procedure SetRect(aleft, atop, awidth, aheight: TfpgCoord);
    function  Bottom: TfpgCoord;
    function  Right: TfpgCoord;
    procedure SetBottom(Value: TfpgCoord);
    procedure SetRight(Value: TfpgCoord);
  end;

So maybe Marco's idea of a new "NOT delphi compatible" RTL is not so crazy after all. At least we will have the freedom of implementing better designs and something that works consistently across all FPC supported platforms. The red-tape will be so much less, but unfortunately the work involved to create a new RTL will be huge.

Regards,
- Graeme -

Graeme Geldenhuys wrote

But then somebody would throw the "not delphi compatible" card at me. I seem to be stuck in a endless loop: I find a issue, report it, get told it's not delphi compatible, everybody ignores issue. Repeat.

I don't get it.

I can see that what Graeme is pointing out does have merit.

Why reject it altogether with an arguement like "it's not Delphi compatible"?

Doesn't FPC have a 'Delphi Compatible' mode, as well as a native mode?

Why not keep the 'Delphi compatible' arguement to 'Delphi mode', but allow it in FPC native mode?

2010/6/9 Adem :

* Because it would be idiotic to change something based on a point of view of one person.
* It would break everyone else's applications.

Doesn't FPC have a 'Delphi Compatible' mode, as well as a native mode?

Afaik that's only for language features (I hope).

Why not keep the 'Delphi compatible' arguement to 'Delphi mode', but allow it in FPC native mode?

Why don't we introduce a GraphicalBounds function?

Henry

In our previous episode, Graeme Geldenhuys said:

Note that this thread confuses two issues:

1 the fact that the default units reflect delphi because of the compability 2 the fact that the non-delphi projects (kol,msegui, fpgui, anybody have any more?) don't pool their
efforts to have common workarounds in a set of units.

The (1) is a namespace problem, and not easily solved.

(2) is way easier fixable since it features additional units, if it is stable enough in say an year, we can enter it it as an FPC package even.

I know (2) doesn't fix everything, like component streaming (which is fixable but only by duplicating classes), but at least it would be a start, and more constructive than the current flamefest.

Adem wrote

Why not keep the 'Delphi compatible' arguement to 'Delphi mode', but allow it in FPC native mode?

In this particular case: unit doesn't have a Delphi and FPC mode. A unit always contains the same functionality.

In general: please take that discussion to the fpc-other list. We already drowned this list with such a discussion last week.

Thanks,

Jonas
FPC mailing lists moderator

Op 2010-06-09 16:06, Henry Vermaak het geskryf:

* Because it would be idiotic to change something based on a point of view of one person.

It's not just one person. Lets just take the Rectangle type/structure.

* Delphi has it's own (based on Windows TRect - how original)
* fpGUI has it's own: TfpgRect
* MSEgui has it's own: rectty
* AggPas has it's own: rect_ptr, rect_d, rect_i
* KOL probably has it's own too
* ... pretty sure there are more....

Regards,
- Graeme -

Graeme,

While I cannot agree with Henry that things cannot change based on a point of view of one person [of course, they can/should --provided that point of view is correct], I do see that such a change can/might play havoc with people's codebases hence not very desirable.

That brings us to Marco's suggestion: It does sound like the best of both worlds.

Couldn't you all 2-3 project leaders (of fpgui, kol, msegui) agree on a common library (that you build gradually) as part of FPC?

I can also that it would take far less time to convince other project leaders on what should go into that lib than it's taking now.

Given that all these projects have been going on for so long, it may not even have to be called beta.

Zitat von Graeme Geldenhuys :

left,top,right,bottom

* fpGUI has it's own: TfpgRect

tell us

* MSEgui has it's own: rectty

left,top,width,height

* AggPas has it's own: rect_ptr, rect_d, rect_i

doubles and C int type. Aggpas is a C port. C people are used to reinvent the wheel.

* KOL probably has it's own too

no

* ... pretty sure there are more....

As far as I can see, every one of the above has a good reason to use their own type.

Mattias

Agreed. ;-)

I don't think the current Bounds() behaviour is stupid. Because of the way it works the definition is the same for integer and float coordinates. Qt uses your approach in QRect because of historical reasons: http://doc.qt.nokia.com/4.6/qrect.html#bottom

and it seems they don't think that it is correct:
"
int QRect::bottom () const
Returns the y-coordinate of the rectangle's bottom edge. Note that for historical reasons this function returns top() + height() - 1; use y() + height() to retrieve the true y-coordinate. "
and
"
There is a third constructor that creates a QRect using the top-left and bottom-right coordinates, but we recommend that you avoid using it. The rationale is that for historical reasons the values returned by the bottom() and right() functions deviate from the true bottom-right corner of the rectangle.
"

This applies for linendings only. XFillRectangle() with width or height = 0 paints nothing AFAIK.

I am not sure if it is possible to design an "ideal" RTL which fulfils all requirements, they are too different.

Martin

Adem wrote

Couldn't you all 2-3 project leaders (of fpgui, kol, msegui) agree on a common library (that you build gradually) as part of FPC?

Based on my experience over the last 6 months alone, I might just investigate this a bit more. But one thing is for sure... If I go down that route, it will be open source of course, but I doubt I'll submit it to the FPC project (for a good few years at least). I'll rather keep it as a separate package (similar to FCL). The last thing I want is yet more red tape.

Go ahead, we'll talk in 10 years and we'll see what you'll do if a single user starts to cry on your mailing list to break the code of thousands of your users only because something doesn't fit according to his logic.

Mattias Gärtner wrote

> * KOL probably has it's own too no

Yup, no.

Florian Klaempfl wrote

Go ahead, we'll talk in 10 years and we'll see what you'll do if a

But you forget, I'll be the only one using the new RTL and fpGUI remember. ;-) You really make it sound like you are the only person that has ever maintained a project for 10+ years - well you're not! Just because FPC had radical changes between v1 & v2 and still doesn't know what it wants to be, other than a Delphi clone (yet Delphi already exists - we don't need two of them), that doesn't mean every other project will have the same pitfalls of FPC.

Graeme Geldenhuys wrote

Just because FPC had radical changes between v1 & v2 and still doesn't know what it wants to be, other than a Delphi clone (yet Delphi already exists - we don't need two of them), that doesn't mean every other project will have the same pitfalls of FPC.

And this exchange makes for another thread that's now moderated.

Jonas
FPC mailing lists admin

[What I am about to raise is off-topic under the current subject line, but not so, IMO, in the light of the above --so, please flame sparingly.]

For several years, I subscribed to Firebird-architect maillist. I didn't have much to contribute other than asking the odd (dumb) question, but it was very educational to me.

But, of course, the purpose of that maillist wasn't that --to educate me--, there they discussed a lot of architectural stuff, usually way above implementation details.

Jim Starkey's presence was extremely valuable as he was practically there when world discovered RDBMSes; and, he would --more often than not-- have tried quite a lot of the bright ideas suggested by other members. He'd list what went right/wrong at the time he tried them and what would it take to avoid pitfalls etc. Or, he would, in a few paragraphs, explain theoretical things you'd spend a semeter to grasp.

So, what I am getting at is this: Is there such a list/platform where only architectural/design issues (no commit details, no coding minutea etc.) are discussed?

If there is, I'd like to subscribe to it as a read-only member [I won't add noise, promise.]

If there's not one, I wonder if people here think it would be a good idea to have one?

2010/6/9 Adem

I always think it is (FPC-DEV). Maybe be im completely wrong.

Donald.

It's not a bug, it's a commonly accepted graphics model.

The only thing I'm missing is a distinction between rectangles in origin-extent and in two-point (TL, BR) representation. IMO two distinct types should be available for these, with according conversion procedures.

DoDi

Or, it is I that's way off the mark.

But, what I had in mind was a forum/maillist where future directions are talked about.

FPC-DEVEL, by definition, gets all sorts of development discussion --from "FPC does not compile on platform X after recent changes" to "Souldn't this function result be this and not that?".

I don't think another list is needed. We have already 3 (not counting Lazarus and the forums, plus IRC), that should be enough.

Michael.