hsauro

I also experimented with caching the scan line pointers, and it seemed to work. I played around a little bit with both image32 and graphics32 but didn’t get very far. The advantage of skia over these other two is that it’s completely cross-platform using the same API and seems to generate very smooth antialiased curves,

That is interesting to know, I didn't have the time to try scanline.

I know it’s discussed before but there is not harm in suggesting it again. Some Embarcadero employees read these forums.

Apparently it’s delayed due to high res dpi issues. It’s good that Embarcadero is having to develop it and discover the problems others have encountered with high res dpi. We might get some fixes as a result.

At least open source the VCL and RTL

What’s been suggested in the first post can already be done to some extent with tms web.

Thanks for doing this, this is one place the community can help. Your efforts might inspire others to contribute.

Nice, I’ll try it, I’ve been recently using skia from python so I’m somewhat familiar with it.

Did you ever resolve your question? I am also interested in accessing numpy to and from Delphi.

Doesn’t look that expensive, $99 for personal copy and $399 for developer.

Thanks for the link. I read through the document, it doesn’t seem such an unreasonable thing to implement for the company. They should allow developers such as yourself to contribute to the libraries, perhaps in return for free licenses. The company either lacks interest, expertise or doesn’t have the bandwidth.

I know it’s off thread, but this sentence piqued my interest, what kinds of defects are you referring to? I used to do more numerical work on Delphi than I do these days but it would still be interesting learn more about these.mmaybe you’ve written them up or mention them somewhere? I just saw your last reply to someone else who had the same question, I think you answered the question there.

Interesting, the page just gives GUI examples but i assume I could compile straight object pascal to webassembly. I should get touch with them to find out more.

It would be fun if there were an object pascal to webassembly compiler.

I notice the new 10.3.1 RAD server console Is not written in Delphi? Any particular technical reason why it couldn’t have been developed in Delphi? Ok I see it’s a browser application, is that the reason?

Slightly off topic I know but what what is the rational for having immutable strings in languages such a Java, Python etc? It seems immutability is related to efficiency and security. I didn’t find the arguments that compelling however. It seems it’s either to stop the programmer from getting into trouble or it makes like easier for the complier writer.

I’m still using Tokyo 10.2 and XE6 for some older projects. Haven’t hamd’t any real problems with either. Will wait for an update before I use Rio.

Using record constructors like this is very convenient but I wonder what the speed penalties are like?

I am measuring the performance of some Delphi code using TStopwatch and I'm seeing considerable variation in the computed times. I run a method 10,000 times and record the time. I then do this 200 times (all within the same program) from which I get an average time of 3.79 seconds for the 10,000 runs with a standard deviation of 0.55. That seems to be quite a large variability. My question is, does TStopwatch measure the total time elapsed or just the time spent on my particular process? If it measures the elapsed time is it possible to measure the amount of time specifically used to execute my code? Herbert

I’ll try that, thanks.

Out of interest, I thought I'd show a scatter plot of the mean and standard deviation from 100 independent runs. Each data point was obtained by measuring how long it took to run a particular method and repeating this 10,000 times and taking the mean and sd for that data. Each set of 10,000 measurements was an independent run started from a batch file. The application itself was run 100 times from the batch file which yields the 100 data points in the plots below. It is interesting to note some outliers around the 35 and 90 iteration. I never touched the computer during this run so this could be some internal housekeeping going on. The standard deviation has quite a bit of variability but ignoring the outliners the mean is fairly consistent at 3.5. Having seen this data I have more confidence in the mean. Y axis is time and x axis is the run number. The code is doing a lot of memory allocation and deallocation of small blocks of memory (16 bytes at a time) and a lot of simple calculations (but no I/O). Out of interest, the following graphs were obtained where all 100 runs were done in the same application. (no batch file) What I thought was interesting is the decline in the standard deviation as the program progressed. Not sure what the blip at 20 or 70 is. Herbert

Exactly that's why I was asking if there was a way to measure the actual amount of time spent in my process and not dealing with everything else which is unpredictable.

My concern was if the time measured is all CPU activity them comparing different implementations of my code run at different times might give unreliable estimates because there could be a different amount of background activity in the two runs. I presume this is the origin of most of the variability I am seeing. I have noticed there is an initial startup component to the variability (cache vs hard drive I assume) and that repeated runs after the first few runs stabilize the times to be less variable. I've noticed that timings I see reported byothers often have no variability estimate on them. Herbert

What is the advantage of using TFileStream with TStreamReader compared passing the filename directly to TStreamReader? For example, what is the difference between these two: f = TStreamReader.Create (fileName) or f = TStreamReader.Create (TFileStream.Create (fileName, fmOpenRead))

Thanks for that. So it's better to use f = TStreamReader.Create (TFileStream.Create (fileName, fmOpenRead)) because one has more control over the flags.