I have a TDatamodule that has a TImageCollection (70 images) and 3 TVirtualImageLists.
Its creation take a lot of time. The .dfm file measures slightly over 400 kB.
I'd like to autocreate this datamodule because the images are used throughout the program.
But in the project source the Application.CreateForm(TDMImageStore, DMImageStore); takes 7-8 seconds (inside/outside the IDE).
Creating the datamodule later only moves the problem in time.
I assume this is all main thread code, any attempts to make a splash screen with an animation therefore fail.
Is there a way to work around this, e.g. create the datamodule in the background?
On program start the user lands in a menu screen which does not need the images yet, so there is some time for this (e.g. no actions requiring the images until a 'created' flag is set).
Win32 program in Delphi 10.4 Sydney.
(If there is no real way around this I can fall back on a static splash screen with an image.)
Related
I'm trying to understand why these Raster processes have such a long duration, but I'm finding the documentation to be sparse.
From other people's questions, I thought it might be related to the images being painted, or javascript listeners, or elements being repainted due to suboptimal CSS transitions but removing the images, javascript, and CSS transitions didn't do the trick.
Would someone be able to point me in the right direction? How do I narrow down which elements or scripts are causing this long process? It's been two days and I'm making no headway.
Thanks!
The "Raster" section represents all activities related to painting. Any HTML page, after all, is an "image". The browser converts your DOM and CSS to the image to display it on a screen. You can read about it here. So even if you don't have any image on the page you still would see as a minimum one rasterizer thread in "Raster" which represents converting your HTML page to the "image".
By the way, Chrome(79.0.3945.79) provides some information if an image was initiated this thread.
Also, you can enable "Advanced paint instrumentation" in "Performance" settings to see in more details what is going on when the browser renders an image
After spending some hours with the same, I believe that the 4 ugly green rectangles called "Rasterize paint" are a bug in the profiler DISPLAY. My suspicion based on:
1) The rectangles start some senconds after the profiler started. NOT after the page loaded, so it seems it is bound to the profiler, not to the page.
2) The starting point of the rectangles depends on the size of the profiling timeframe. If I capture 3 seconds it starts after ~2 secs, if I capture 30 seconds it starts after ~20 secs. So the "cpu load increase" depends on the time you press the stop button.
3) If I enable "Advanced paint instrumentation" as maksimr suggested, I can click on the rectangle to see the details, and the details show ~0.4 ms events in the "Paint profiler", just like before the death rectangles started. (see screenshot, bottom right part)
3b) I even can click on different parts of the same rectangle, resulting different ~0.4 ms long events in the Paint profiler...
I am developing an aframe project on my MacBook pro, late 2013. When running the project, the fan of my computer always spins fast, regardless which browser I use (firefox, safari, chrome) and the project size (also happens with a project just containing a simple a-box).
aframe-stats show me that my project (1028244 vertices, 342748 faces) still runs with 20 fps.
Is it somehow possible to limit the frame rate to 10fps in order to keep my computer quite? Or any other way to limit the flop-consumption of the aframe project? I already tried a native approach with sudo cputhrottle plugin-container 10 but that did not just throttle the aframe-renderer but the whole firefox browser. Can I pull the break somewhere in the JavaScript or the Browser settings?
It's difficult to say without your project code. Large data sets will simply crank out even a high spec macbook pro. I have found it helpful to pause any rendering whenever possible to quiet the users' machines.
I personally removed automated next animation frame rendering in favor of waiting for controls and objects to change.
For example:
this.controls.addEventListener( 'change', function(e){ addToRenderStack(); });
A simple function addtorenderstack puts in a new value in a list for a render, with the expectation that the render will occur at some point in the future and not right away. the list can also be used to log who requested the render in the call stack, and narrow down performance hogs.
addtorenderstack places a render request in a list. In the requestanimationframe loop, if the list has any length, a render is called on the scene. The stack is immediately cleared rather than processed one by one. If controls or animations continue to make render requests, the list will have a length again and request animationframe will process them in the same way with another render.
In this way, the code only renders when absolutely required. This saved me much grinding on framerate and the fans only come on during intensive operations and then shutdown when its complete, much like a typical 3d game experience.
Your mileage may vary depending on what's happening in your app. I work in engineering so often the view of the 3d world is stopped as an engineer examines or shows a model.
I'm trying to benchmark the loading of large images in Corona SDK.
local startTime = system.getTimer()
local myImage = display.newImageRect( "someImage.jpg", 1024, 768 )
local endTime = system.getTimer()
print( endTime - startTime ) -- prints 8.4319999999998
This returns values of around 8 ms. I know it takes longer to load an display an image because if it really took 8 ms I wouldn't notice the delay, but I do notice it. I'd say it takes about 300 ms.
Also the FPS drop drastically when loading a large image. I'm monitoring this using an enterFrame event and when loading the image it prints values of around 0.3 for 1 frame.
Runtime:addEventListener( "enterFrame", myListener )
function onEnterFrame (event)
print( display.fps )
end
The frame takes a long time to render when loading, even when the loading of the image takes less than 1/60 of a second. I guess it means the rendering is happening asynchronously somewhere else.
So, how can I measure the time it takes to really load and display an image?
Since Corona SDK is closed source, we'll have to use the docs and imagination.
I see three possibilities here:
Corona is doing what it says, and your subjective experience is wrong.
Corona is loading the images in a background thread, so the call to display.newImageRect is non-blocking: it "starts" loading the image, and then continues. When this happens in other SDKs (mostly javascript-based ones) you get a "ready callback" that you can use on the image object, but I could not find such thing in the docs.
Corona loads the image quickly, but requires "extra work afterwards". For example, it generates lots of garbage which has to be garbage-collected. So the image gets loaded fast, but then this "extra work" slows down the app.
My bet is on 3. But this doesn't really matter. Independently of which one of these options is causing the slowdowns, they can be solved the same way: instead of loading the images right before you draw them, you have to preload them.
I don't use Corona SDK, but a quick google pointed me to the storyboard module, in particular to storyboard.loadScene.
Create a new scene, list all the images that you need on it, and load it before showing it - that way image loading will be done in advance, not slowing down your app.
Most likely the image is rendered during the scene's rendering loop. There is no event to indicate that an image has been rendered. However if you create the display object in the scene's create event handler or a button click handler, and register an enterFrame event handler, you can measure the time between that and the first frame event. I can't try this here but my guess is this will give you an estimate of the time to render the image. Dont use FPS. Larger image will probably give you a larger measurement. If you measure the time between enterFrame events you will probably find that it is much smaller than the time between create/click event and the first frame event, or between the first two frame events after the create/click event. Post a comment if you would like to see some example code.
Some weeks ago a user reported that the GUI of my program was shrink.
Today I started my laptop in multi-monitor mode and could reproduce the problem: at windows start up, the size of the main form was 325x243 pixels instead of 648x700.
I have no single line of code that controls the width/height of the form. The position is set like this: MainForm.Position:= poDefault. The user cannot resize the form ( BorderStyle:= bsSingle ).
What could cause such weirdness?
It is the second time when I start my laptop with additional monitors attached. The first time everything was ok. Could it be related to this multi-monitor configuration?
If the compiler generates no code related to form's size then it is like some external program injected code into my program to change its size. It is plausible. There are programs that are doing so in order to control how windows are spread over multiple monitors. I have one of them installed but it is not running at Windows start up.
The position is set like this: MainForm.Position:= poDefault
And that is the answer.
http://docwiki.embarcadero.com/Libraries/XE4/en/Vcl.Forms.TForm.Position
The form appears in a position on the screen and with a height and width determined by the operating system.
However there are other options like
poDefaultPosOnly: The form displays with the size you created it at design time, but the operating system chooses its position on the screen
poScreenCenter: The form remains the size you left it at design time, but is positioned in the center of the screen.
And many others.
Additionally, you may avoid fixing the issue and add a workaround instead: just set the form size fixed using http://docwiki.embarcadero.com/Libraries/XE4/en/Vcl.Forms.TForm.Constraints
An old game (Pod) is kept alive with a glide wrapper and thus can now be run in custom resolutions larger than the native game resolution which was 640x480.
However, due to problems with the glide wrappers, if the game is run at 1920x1080 for example, the cursor is only allowed to move in a 0, 0, 640, 480 rectangle; obviously the WinAPI ClipCursor function has been used by the original developers for this.
This is pretty nasty because you can't act with the game menu mouse-wise in a useful way since not all buttons can be reached.
Is it possible to disable ClipCursor() functionality globally? Do I have to inject a DLL (I didn't do this completely before) or would it just be enough to let a C# app run in the background, watching for the game process and setting ClipCursor() to the real screen area after the process has been started?
I seriously doubt it's calling ClipCursor() more than once. Try writing a small program to call ClipCursor() and set it back to the size of your desktop. Run that program after your game is started.
edit
Depending on your skill level, you could also try using ollydbg to step through the program and find where it's calling the ClipCursor() API, and insert a jump to skip over it.