Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 01/11/21 in all areas

  1. True. However, when using Process Monitor, the user can see WHEN the file is being opened by his app in real-time. Maybe he can match that up to a specific operation the app is performing at that time, and then he can track down the code behind that operation to see if it is leaking the file handle.
  2. Before doing any deep optimizations, run benchmark to ensure that serialize really is the source of slowdown. Otherwise you could spend hours achieving nothing in the end
  3. @Anders Melander I recently saw this post from you, as a maintainer of the wonderful Graphics32 libary. https://en.delphipraxis.net/topic/4140-smooth-scaling-of-bitmaps/?do=findComment&comment=36266 So I hope that you and/or others might have more insights about the future of the Graphics32 project. I used it in the past very successfully, and would also nowadays bet on it, but the activity of this project is quite slow. Why is that, I cannot really understand ? I have seen attempts from ZhaoyiPeng, to bring Gr32 to FMX, but also this moves quite slow, or is stalled. I see effords from Angus Johnson, to push a new Image32 project. Is the Image32 based partly on Graphics32 technologie ( I'm afraid its not), or how does it fit all together ? I had no time to look into all that more deeply, but the Gr32 for FMX seems to be only a proof of concept, and many features still missing. My original though was that Gr32 is able to use different backends, so it might be possible to port this to FMX too. Since FMX makes use of GPU, I'm not really sure if Gr32 can beat this, but I think Gr32, on the other hand, has features that were not available in FMX right now, and still would make sense. Anyhow, beside FMX, for VCL this seems to be still the great choice for bitmap operations. So what is the status and the roadmap of this project ? Would be good to know. Is this lack of maintainers or lack of interested users ?
  4. Hmm I guess some of us has had too little sleep at night because I don't get your point. Of course properly named parameters of enum type carry more info than plain boolean. But they involve too much overhead and pollute namespace so I prefer a little bit of mystery the booleans bring
  5. Fr0sT.Brutal

    Default code style

    When inserting a piece of code, its default style is for some reason "HTML". Here, at Delphi forum, it seems like a annoyance generator invented by the devil 🙂
  6. I use Booleans as options for functions from time to time. Yes they add some guess work but defining a special enum type for every function is too hard for me. I hope I'll never deal with a library that would force me to do something like FindFiles('c:\', TFindFilesOptions.Subdirs)
  7. Well, you're like "If a thief is managed to get into your house, it's already game over". But that's not true and "Home alone" proves it earnestly 🙂 Jokes aside, different cases require different measures. Your sentence asserts that any kind of software running on machines which limited users could access is a priori will be hacked. I don't think so.
  8. Dalija Prasnikar

    The Case of Delphi Const String Parameters

    I don't know if there is some other reason, but one reason is that with interlocked reference count you can freely use reference counted instances of any type (interfaces, dynamic arrays...) in multithreaded environment for read access if all threads have acquired their strong reference before original reference has been written to (cleared or assigned). In such case you don't need any other more costly locking protection, and you can share same string, so no copying necessary. Clearing such references when they go out of scope is thread safe, because memory deallocation will happen only in case where reference count reached 0. Also getting strong reference from strong reference (variable) held by thread is also thread safe - when I said held by thread it means that no other thread is allowed to write to that variable.
  9. Anders Melander

    What is the future roadmap of Graphics32 ?

    Yes, that was my assumption. You can use the Graphics32 to map from a quadrilateral to a rectangle too (for example I use it for perspective correction), but it's true that one of the quadrilaterals must be a rectangle. However since it can do both forward and reverse transformation you can actually use two of them to do quadrilateral to quadrilateral transformation although that would not be very efficient. A better way would be to use one to create the source matrix, use a second to create the destination matrix, multiply the first with the inverse of the second and use the result as the transformation matrix. I believe that's also the method you use. I.e. Matrix = SrcMatrix * Adjoint(DstMatrix) True, but I don't think Graphics32 has ever targeted the average user. It does have a steep learning curve and does require an understanding of at least some of the low level principles - such as alpha compositing.
  10. Which is why many servers insist on using JOSE technologies such as Json Web Signing which means the headers are signed with a password or private key before being sent, so can not be changed without the server knowing, this is how Let's Emcrypt and OAuth1/2 work. Or Json Web Encryption if you don't want the headers read. Angus
  11. Dalija Prasnikar

    The Case of Delphi Const String Parameters

    Sure... yep... this is my imagination running wild... https://en.wikipedia.org/wiki/Value_type_and_reference_type There is no common sense there is clear definition what reference type is and what value type is. You can always see address stored in any reference type, including string. It just requires typecast.
  12. I also highly recommend the book "Code Complete 2nd Edition by Steve McConnell"
  13. If a method does two diverse actions, define two methods. If a method performs an action which is something on/off or enabled/disabled then you can use a boolean, if the false/true statement is clearly defined by the naming of the method. If a method performs something, but with a custom behavior, don't use boolean (or booleans) but an enumeration or even better a set. It will be much more easy to understand what it does, without looking into the parameter names, and it will be more open to new options/behaviors. function TMyObject.SaveTo(json: boolean): string; // what is the behavior with json=false? function TMyObject.SaveToJson(expanded: boolean): string; // what does SaveToJson(true/false) mean without knowing the parameter name? function TMyObject.SaveToJson(expanded, usecache: boolean): string; // what does SaveToJson(true/false, true/false) mean without knowing the parameters names? type TMyObjectSaveToJsonOptions = set of (sjoExpanded, sjoUseCache); function TMyObject.SaveToJson(options: TMyObjectSaveToJsonOptions): string; // you understand what does SaveToJson([]) or SaveToJson([sjoExpanded]) or SaveToJson[sjoExpanded, sjoUserCache]) mean
  14. It's strange then that you don't seem to read what people post. I get a sense sometimes that you ask questions but have already decided what the answer is.
  15. Names mean nothing. You have to understand what people say, and judge it for yourself. Stop following people blindly based on reputation. Try to develop your own critical assessment of what you read.
  16. Nick's point is fine. I think you just misunderstood it to mean that you needed to replace all boolean args. Following somebody else's recipe without really grasping the issue won't make your code any better. It will just give you work to do and make it likely that you will introduce bugs to your code? If you don't have comprehensive tests for all of your code then you are in big danger of that.
  17. David Heffernan

    The Case of Delphi Const String Parameters

    This makes no sense whatsoever.
  18. Dalija Prasnikar

    The Case of Delphi Const String Parameters

    I wrote more elaborate post on const parameters https://dalijap.blogspot.com/2021/01/are-const-parameters-dangerous.html
  19. Anders Melander

    What is the future roadmap of Graphics32 ?

    Hi Angus and welcome Well, if all you want is a hammer then all the other tools may indeed seem like bloat. The VPR polygon renderer and the line methods solve two different but similar problems. Remember that the purpose of Graphics32 is to do things as fast as possible. This means specialization over generalization. VPR is a generalized vector renderer that does many things reasonably well while the line methods does one single thing as fast as possible. That's why, instead of a single line method with a bunch of parameters, we have individual methods for vertical lines, horizontal lines and "other" lines. It's also why each of these methods are found in different variants each supporting different feature combinations: clipped or unclipped coordinates, transparency, anti alias or not, patterns, etc. And for different numeric types: integer, floating point or fixed precision. It's all about avoiding compromises that would hurt performance and give the user of Graphics32 control over the choices that have an impact on performance. Replacing the line methods with VPR would be like putting all-weather tires on a Formula 1 car. The MoveTo/LineTo methods, like their TCanvas counterparts, are purely high level convenience methods that will be superseded and can be removed once the TCanvas32 rewrite gets merged. But that's being blocked by the 2.0 non-release Interesting. It looks like it should be easy to adapt that algorithm to the Graphics32 transformation framework. I'll give it go and compare it to the existing one.
  20. angusj

    What is the future roadmap of Graphics32 ?

    That was indeed my initial intention. However, the more I tried to remove what I considered obsolete code, the more problems I encountered as I found what seemed obsolete was still used by other parts of the library. For example TCustomBitmap32 has 14 different Line methods, 7 LineTo methods, 7 HorzLine methods and 7 VertLine methods. That really is excessive and IMHO should be removed and intead use the separate and much more flexible polygon renderer (in GR32_VPR). I'd disagree with Anders on that, though of course I could still greatly improve Image32's design. It's fair to say the TImage32 class that's at the core of my Image32 library does have a large number of methods related to loading and saving images, as well as a number of image manipulation methods (including hue adjustment and basic afine transformations - scale, rotate etc). But most of these methods (or similar) also appear in Graphic32's TBitmap32 class. IMHO Graphic32's TBitmap32 is much more monolithic, as it containing a whole host of line rendering methods (as mentioned above) and text (polygon) rendering methods too. These really shouldn't be there, as these operations are much better served by the functions found in Graphic32's Gr32_VPR unit. Further, TBitmap32's line rendering methods will only draw 1 pixel wide lines which is extremely limiting. So I would argue that my TImage32 class is much less monolithic than the TBitmap32 class. Almost none of my Image32 libray uses code from Graphics32. The excepion to that is a small amount of code in my Image32_Draw unit where the polygon renderer uses a memory allocation technique I copied from Mattias Andersson's Gr32_VPR unit. (When comparing Image32 rendering performance with Graphics32, I couldn't figure out how Mattias' rendering was so efficient.) Nevertheless my polygon renderer is based on https://nothings.org/gamedev/rasterize , though it still isn't quite as fast as Mattias' renderer. I did also briefly copy Projective Transform code from the Graphics32 library (with attribution), but that was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution). With regard to which library is better, I suggest if you're familiar with Graphics32, or if polygon rendering performance is critical, then use Graphics32. However, Image32 does offer several benefits over Graphics32. It's a much simpler library to learn and use IMHO and it contains better cross-platform support with both Lazarus and FMX options.
  21. Anders Melander

    What is the future roadmap of Graphics32 ?

    The Graphics32 team First of all I'm not the maintainer of Graphics32. I'm just a contributor. I don't even have admin rights to the main repository. As far as I'm concerned the current project lead is @CWBudde1 but I'm not sure he agrees and he's also been largely absent in a long time. Of the remaining 4 members, micha137 hasn't contributed anything significant in a year and Michael Hansen, Mattias Andersson and Andre Beckedorf hasn't been active in a decade. https://github.com/graphics32/graphics32/graphs/contributors (I'm not sure how reliable that page is as I seem to be absent from it). Roadmap The last roadmap I know of was from 2012 (posted in the old graphics32 newsgroups) and concerned the "mythical version 2.0". Since then some of the items on the roadmap has been implemented, some has been superseded and some things not on the roadmap has been added. At present only the Graphics32 issue tracker at Github gives any indication of the direction the project might move. Lack of progress From my POW the inability to make a decision and actually release version 2.0, incomplete or not, has been one of the reasons why the project has stalled. For example the present version supports Delphi 7 and later which greatly limits what can be done - or what people are willing to do. A new version would drop support for ancient versions of Delphi and only support XE and later. In April 2019 it was decided, by Christian, Angus and I as far as I recall, that we should just release version 2.0 as-is. But again, without anyone to take the lead, nothing happened. In my opinion the greatest blow to Graphics32 was the complete loss of the Graphics32 community. This happened when the project was moved to Github and people stopped using the newsgroups. Github is great for managing the project but it's not a community platform. Without a community we're left with individual developers that might still have an interest in the project itself but soon burns out or simply isn't interested in developing in a void with no interaction with others or feedback from the users. Apart from the discussions and QAs, a big part of the old newsgroups was that people posted examples of what they did with Graphics32 and how they did it, extension libraries and graphic algorithm implementations. Luckily I still have an almost complete local copy of the newsgroups and it's still a great resource for inspiration, examples and solutions. Actually it seems the usenet server is still alive: nntp://news.graphics32.org Of course one needs a news client to access them and I'm probably one of the last people on earth to have one installed Image32 I have read the Image32 documentation and I think I've looked at the source once but beyond that I have little knowledge about the project. I would be very surprised if Angus didn't use the techniques used in Graphics32 as inspiration. Although I know he loves to write things from scratch I doubt that he doesn't use Graphics32 as a reference. Anyway, I can only guess. As far as I can see the "architecture" of Image32 is that there isn't one; While Graphics32 is an object oriented framework on top of some highly optimized low level routines, Image32 is more of a monolithic design - one class does everything. As far as I remember this dislike of OO was one of the reasons he wanted to write his own. Another was that he felt Graphics32 had become bloated. I don't agree but that's beside the point. Current state of the project As I see it the current version (i.e. head in the master branch) is stable. There are no grave issues and nothing technical that hinders future adoption of the library into new projects. The documentation has fallen behind and in a few places it is no longer correct. The examples aren't that great but at least they compile and do what they were written to do. The future As I'm just another contributor I can only speak to what I would like to see happen. Someone has to take the lead. It could be me but then I would have to stop contributing code. I can't do both. Also, although I do have opinions about how and what should be done my area of expertise is architecture and implementation. Get 2.0 released or simply abandon the idea of major release versions. As I said above before the 2.0 problem is resolved there will be little or no progress. Move the documentation into a wiki so we're actually able to maintain it. Currently it seems updating the documentation requires custom tools and I for one don't need the hassle of building, installing and maintaining some tool just to keep the docs up to date. It's hard enough to find the motivation to do so without that. Separate the examples from the showcases and write some (or a lot) of small, simple examples that demonstrate how to get started with Graphics32 and how to solve the most common tasks/problems. Even I hardly look at the current examples when I need to figure out how to do something as they are mostly too advanced or bury the relevant code in unrelated gimmicks. I can imagine that they must be undecipherable to a new user. Get rid of or repair the code contributed by cowboys. Some of the newer features of Graphics32 was contributed (and accepted) without regard for the fact that other people should be able to maintain it (for example if the author went awol or decided to work on another project instead). The code should be commented, the algorithms used should be documented, etc. Even if none of the above happens I think Graphics32 will be safe for the immediate future. It's a stable and fairly complete library and there are enough people and projects using it that someone else is bound to pick up the mantle if all the current contributors get hit by a bus.
  22. If you've managed to be able to execute code on the target's machine, it's already game over. Bulleting passwords is only ever intended to stop over the shoulder password theft. See point 1. No matter since points 1 and 2 are invalid.
  23. David Heffernan

    SMS via my phone..

    Why do you need a phone? Wouldn't it be easier to do it without the phone?
×