Re: [Lazarus] TPicture width questions (duplicate ways)
On 2017-03-10 11:01, Kostas Michalopoulos via Lazarus wrote: You can check yourself easily: Ctrl+Click on the p.Width to go to the definition of the property, then Ctrl+Click on the GetWidth getter, Ctrl+Shift+Down arrow to see the code for the getter and see that it simply gets FGraphic's property. You can check the current sources but that does not mean it will stay that way, or that the current sources do not have a bug in them... the documentation would tell you how it is supposed to act, and, the source is one particular implementation, which could not match up with what the doc says, in that case it is buggy ;-) But thanks very much for explaining it: indeed I figured any call to .jpeg.someproperty would immediately automagically do the work for you So what is FGraphic? Ctrl+Home to move at the top of the source code (you'd be in picture.inc) and search for "FGraphic :=" to see where it is assigned (the source code style in that file seems to put a space before := in assignments). You can see that it is used in a bunch of places, so you can see where those uses are. ForceType is the first one and if you search for that one, you'll find that it is used wherever a type-specific property (p.Jpeg, p.Bitmap, etc) is used - presumably to convert the underlying graphic to the requested type. So the FGraphic object is actually an instance of the TBitmap, TPortableNetworkGraphic, TJpegImage, etc (depending what you loaded and/or accessed last). This is very useful - I thought maybe it would be in a wiki or docs somewhere.. It may be... So what p.Width gives you is the FGraphic's width or 0 if there is no FGraphic loaded (because a picture may have nothing loaded until you either load it directly or try to access any of the Bitmap, Jpeg, PNG, etc properties). So if you already have a picture loaded from a PNG file, p.Width, p.Graphic.Width and p.PNG.Width will give you the same number. If your picture doesn't have a graphic (e.g. it is a newly constructed object) then p.Width gives you 0, p.Graphic.Width will crash your program (FGraphic is nil) and p.PNG.Width will give you zero (because accessing the PNG property will call the ForceType function which will create a TPortableNetworkGraphic object that by default is undefined and gives you zero width). Question for the readers: what happens to the image if you load a PNG file with alpha values using TPicture's LoadFromFile, access the TPicture.Jpeg.Width property and then save the picture as a PNG file using TPicture's SaveToFile? Is the alpha component preserved? Do you get jpeg artifacts? Why? Bonus question: why is R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height) worse than R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height)? Why is R := Rect(0, 0, p.Width, p.Height) better than either of them? You can find the answers to those (and many more) using Ctrl+Click, Ctrl+Shift+Up/Down Arrow, Search and back and forward buttons (helps to have a mouse with those). Considering how big and complex LCL is, it helps to be able to navigate and familiarize yourself with its source code :-). IMO the docs should always describe the theory of an object/procedure, and therefore if any time the source code is buggy, the docs are the official sources to what a function does.. :-) Thanks much for documenting it in this mailing list ! Some of your comments, IMO should be uploaded to wiki/docs somewhere But I'm unfamiliar with how the docs updating process works -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPicture width questions (duplicate ways)
Of course the second part should have been Rect(0, 0, p.Jpeg.Width, p.Jpeg.Height)? :-P On Fri, Mar 10, 2017 at 7:01 PM, Kostas Michalopoulos < badsectorac...@gmail.com> wrote: > You can check yourself easily: Ctrl+Click on the p.Width to go to the > definition of the property, then Ctrl+Click on the GetWidth getter, > Ctrl+Shift+Down arrow to see the code for the getter and see that it simply > gets FGraphic's property. So what is FGraphic? Ctrl+Home to move at the top > of the source code (you'd be in picture.inc) and search for "FGraphic :=" > to see where it is assigned (the source code style in that file seems to > put a space before := in assignments). You can see that it is used in a > bunch of places, so you can see where those uses are. ForceType is the > first one and if you search for that one, you'll find that it is used > wherever a type-specific property (p.Jpeg, p.Bitmap, etc) is used - > presumably to convert the underlying graphic to the requested type. So the > FGraphic object is actually an instance of the TBitmap, > TPortableNetworkGraphic, TJpegImage, etc (depending what you loaded and/or > accessed last). > > So what p.Width gives you is the FGraphic's width or 0 if there is no > FGraphic loaded (because a picture may have nothing loaded until you either > load it directly or try to access any of the Bitmap, Jpeg, PNG, etc > properties). So if you already have a picture loaded from a PNG file, > p.Width, p.Graphic.Width and p.PNG.Width will give you the same number. If > your picture doesn't have a graphic (e.g. it is a newly constructed object) > then p.Width gives you 0, p.Graphic.Width will crash your program (FGraphic > is nil) and p.PNG.Width will give you zero (because accessing the PNG > property will call the ForceType function which will create a > TPortableNetworkGraphic object that by default is undefined and gives you > zero width). > > Question for the readers: what happens to the image if you load a PNG file > with alpha values using TPicture's LoadFromFile, access the > TPicture.Jpeg.Width property and then save the picture as a PNG file using > TPicture's SaveToFile? Is the alpha component preserved? Do you get jpeg > artifacts? Why? > > Bonus question: why is R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height) worse > than R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height)? Why is R := Rect(0, 0, > p.Width, p.Height) better than either of them? > > You can find the answers to those (and many more) using Ctrl+Click, > Ctrl+Shift+Up/Down Arrow, Search and back and forward buttons (helps to > have a mouse with those). Considering how big and complex LCL is, it helps > to be able to navigate and familiarize yourself with its source code :-). > > > On Thu, Mar 9, 2017 at 7:44 PM, Lars via Lazarus < > lazarus@lists.lazarus-ide.org> wrote: > >> On 2017-03-09 10:48, José Mejuto via Lazarus wrote: >> >>> >>> AFAIK: >>> >>> TPicture.Width is the TGraphic container size. >>> TPicture.jpeg.Width is the width declared in the jpeg image. >>> TPicture.Bitmap.Width is the width of the bitmap in pixels. >>> >>> Mostly the 3 will have the same value but extracted from different >>> sources. >>> >>> >> If I start off using a bitmap, and all of a sudden start using jpeg, will >> it automagically work or does one have to initiate the jpeg in some way? >> >> Example: you start off working with a classic BMP, but then 60 lines of >> code later you want to work with it as a jpeg. Do you just magically start >> working with a jpeg without any worry, or you have to take some precautions? >> >> Likely, this is explained in a article on the wiki somewhere, I don't >> know :-) >> >> -- >> ___ >> Lazarus mailing list >> Lazarus@lists.lazarus-ide.org >> http://lists.lazarus-ide.org/listinfo/lazarus >> > > -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TPicture width questions (duplicate ways)
You can check yourself easily: Ctrl+Click on the p.Width to go to the definition of the property, then Ctrl+Click on the GetWidth getter, Ctrl+Shift+Down arrow to see the code for the getter and see that it simply gets FGraphic's property. So what is FGraphic? Ctrl+Home to move at the top of the source code (you'd be in picture.inc) and search for "FGraphic :=" to see where it is assigned (the source code style in that file seems to put a space before := in assignments). You can see that it is used in a bunch of places, so you can see where those uses are. ForceType is the first one and if you search for that one, you'll find that it is used wherever a type-specific property (p.Jpeg, p.Bitmap, etc) is used - presumably to convert the underlying graphic to the requested type. So the FGraphic object is actually an instance of the TBitmap, TPortableNetworkGraphic, TJpegImage, etc (depending what you loaded and/or accessed last). So what p.Width gives you is the FGraphic's width or 0 if there is no FGraphic loaded (because a picture may have nothing loaded until you either load it directly or try to access any of the Bitmap, Jpeg, PNG, etc properties). So if you already have a picture loaded from a PNG file, p.Width, p.Graphic.Width and p.PNG.Width will give you the same number. If your picture doesn't have a graphic (e.g. it is a newly constructed object) then p.Width gives you 0, p.Graphic.Width will crash your program (FGraphic is nil) and p.PNG.Width will give you zero (because accessing the PNG property will call the ForceType function which will create a TPortableNetworkGraphic object that by default is undefined and gives you zero width). Question for the readers: what happens to the image if you load a PNG file with alpha values using TPicture's LoadFromFile, access the TPicture.Jpeg.Width property and then save the picture as a PNG file using TPicture's SaveToFile? Is the alpha component preserved? Do you get jpeg artifacts? Why? Bonus question: why is R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height) worse than R := Rect(0, 0, p.Jpeg.Width, p.PNG.Height)? Why is R := Rect(0, 0, p.Width, p.Height) better than either of them? You can find the answers to those (and many more) using Ctrl+Click, Ctrl+Shift+Up/Down Arrow, Search and back and forward buttons (helps to have a mouse with those). Considering how big and complex LCL is, it helps to be able to navigate and familiarize yourself with its source code :-). On Thu, Mar 9, 2017 at 7:44 PM, Lars via Lazarus < lazarus@lists.lazarus-ide.org> wrote: > On 2017-03-09 10:48, José Mejuto via Lazarus wrote: > >> >> AFAIK: >> >> TPicture.Width is the TGraphic container size. >> TPicture.jpeg.Width is the width declared in the jpeg image. >> TPicture.Bitmap.Width is the width of the bitmap in pixels. >> >> Mostly the 3 will have the same value but extracted from different >> sources. >> >> > If I start off using a bitmap, and all of a sudden start using jpeg, will > it automagically work or does one have to initiate the jpeg in some way? > > Example: you start off working with a classic BMP, but then 60 lines of > code later you want to work with it as a jpeg. Do you just magically start > working with a jpeg without any worry, or you have to take some precautions? > > Likely, this is explained in a article on the wiki somewhere, I don't know > :-) > > -- > ___ > Lazarus mailing list > Lazarus@lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mac users: High-DPI
On 2017-03-09 21:25, Alexey via Lazarus wrote: > No problem so? Something different. See attached screenshot. You got to laugh at Canonical (ie: Ubuntu) for thinking this is a good design! The menu and window title all being garbled. Can't they just leave menus the way they were - or if they want to copy OSX, at least doing a decent job of it. WTF! Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mac Hi-DPI 2
On 10.03.2017 6:38, Alexey via Lazarus wrote: seems I cannot see how scaling works on Mac. Reason: MacOS don't scale coords of controls, and don't have event "scale changed". It scales using Retina thing when i call video mode "nnn x nnn hi-dpi". It means: only DPI changes, coords dont change (controls must draw in high dpi, but on same x,y-x2,y2) To me it looks like Carbon applications are scaled automatically by the OS. Something similar to what also Windows uses if you switch High-DPI awarness off. That means the regardless of your screen (retina, non-retina) the DPI is always 96. So there shouldn't be any LCL-scaling involved. It's only what I see from the pictures and the code, I cannot test it myself because I don't have a retina screen to check. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mac Hi-DPI 2
>To me it looks like Carbon applications are scaled automatically by the OS. Something similar to what also Windows yes, it is what I see too. Scaled automatically by OS >That means the regardless of your screen (retina, non-retina) the DPI is always 96. So there shouldn't be any LCL-scaling involved. yes. right. But i tested only 10.8, and not sure about new OSes, 10.11, 10.12... -- Regards, Alexey -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mac users: High-DPI
On 10.03.2017 4:22, Alexey via Lazarus wrote: On 10.03.2017 01:01, Ondrej Pokorny via Lazarus wrote: But actually I now tested the font problem on Mac: Lazarus 1.6: Font.Size=8 (or any other value) results in different visual font height on Windows and Mac. Lazarus trunk: Font.Size=8 (or any other value) is the same height on Windows and Mac. Yes, i posted the same info in above msg, with 2 screenshots (from OSX and Linux Cudatext editor) and wanted to say that font looks of same size. So no problem with bigger font on Mac Alexey, thank you for the screenshots. It means that before r53712 the Linux and OSX font was rendered with different size. So everything is good now :) Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Mac users: High-DPI
Ondrej, 2 pictures. Cudatext on Linux, text font size =9. Cudatext on OSX 10.8, font size (other font but siimilar) =9. Font size looks same. on both OSes. No difference 30-50%. (Mac Font dialog shows size=12 for LCL font size=9. you know.) No problem so? Alex -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
