Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I have a WPF application that needs to provide feedback to the user. I use a WPF window (progress window) with couple of Progress bars that I tried to update using:
Calling a method on the progress window and change the values of program bars
Binding the value of progress bars to a ModelView
Both perform the same.
[Demonstration Application Download][1]
The performance is really slow if I update the progress values every time through the loop. It gets better depending upon how often I update the progress value.
The Demonstration Application gives me the following times:
Interval Overall Loop Time
1 23:46 seconds
10 3:09 seconds
100 :42 seconds
1000 :05 seconds
I would like to report progress every time through the processing loop. How can that be done?
In my "real" application the processing loop does a lot of processing but updating the progressbar for each unit of work is slow.
A general approach to designing well behaved applications that need to do processing is that the work should be done on another thread, with periodic messages posted back to the UI to update it on progress. BackgroundWorker may suit your application - https://msdn.microsoft.com/en-us/library/cc221403%28v=vs.95%29.aspx?f=255&MSPPError=-2147217396
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 days ago.
Improve this question
I need a very simple example in C, using the XCB library. With a simple window that, when moved, shows its x and y position in the title or terminal. One event that works to capture motion is XCB_CONFIGURE_NOTIFY.
Preferably counting its borders and title, that is, that when I position it in the upper left corner it actually marks 0,0.
My difficulty started the moment everything I tried only displays 0.0 in any position or at most 5.19 in the top left corner.
NOTE:
Please, don't use examples of Xlib or any other library that someone's imagination has. I want to learn XCB!
Examples only in the C language, remembering that C is not C++.
For those who want to know why: NONE important! What comes to mind at this moment is being able to see on my screen what size I imagine I'll need for something else, because for me this is just basic!
And no, I don't want to use a ruler on the screen to know the size of my window :)
I tried several like: xcb_get_geometry (All), xcb_translate_coordinates, xcb_configure_notify_event_t, xcb_expose_event_t
Found a solution. See below.
I am using GTK 3.8 gtk_grid in a scrolled window. The C code works through a lot of data and displays some in the grid. GTK does not draw the grid until the program finishes processing all data. How do you force GTK 3 to refresh the screen when you add data?
I tried gtk_widget_queue_draw but nothing happens.
I also tested gtk_widget_show_now but nothing happened.
The process might run for a few seconds or many minutes. The user can select the range of data to display and the refresh. The refresh might be every 5 seconds or every 10 rows. I would be happy if either worked.
The only relevant question I can find is on GTK 2 and recommends gtk_widget_queue_draw which does not work. I read all the GTK documentation and that recommends the same function. Something is missing in the documentation, examples, and answers.
From what I can see, I would have to process 100 rows then stop and display a button to request the next 100. This is not viable. The user needs the data scrolling through to the end.
GTK_grid appears to have changed a few times in version 3. I am not locked into GTK_grid if there is a more efficient or effective way to display rows and columns. There is no option to revert to an earlier GTK.
I found something that works in GTK 3.8. Add a line after gtk_widget_queue_draw:
gtk_widget_queue_draw(results);
while (g_main_context_pending(NULL)) {
g_main_context_iteration(NULL,FALSE);
}
Read The Main Event Loop for more details.
There are a lot of topics about different drawing approaches in WPF. Starting from Shapes and Polygons, ending with low-weight DrawingVisual and BitmapCache.
However, when it comes to frequent redrawing, say, moving line once per 16 ms (equal to 60 times per second), it appears to be choppy. And none of these approaches seems to provide required update frequency and smooth movement.
So the question is, how can it be achieved?
NOTE: I came up with this question after describing my issue in details in another topic: How to achieve smooth UI updates every 16 ms?
Solution was found. Using CompositionTarget.Render is the way to go!
http://msdn.microsoft.com/en-us/library/ms748838%28v=vs.110%29.aspx
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'm an Amiga programming newbie.
I need to produce an application that displays graphics in a similar way to the popular drawing application, Deluxe Paint by Dan Silva, published by Electronic Arts. Just a vertically scrolling image, preferably in HAM mode.
How do I open a new screen based on the result from a screenmode requester dialogue box using HiSoft C for the Amiga?
Requirements:
Open a new hires interlaced screen in as many colours as hardware will allow
Basic menu structure that I can manipulate (Top Right-click menu)
A project window, similar to the HiSoft C editor
A control panel along the top similar to the one in Digita Wordworth with text boxes, buttons and tabs
I also need an off screen buffer that is as wide as the screen and as tall as memory will allow.
This needs to be compatible with:
Workbench 3.0 and above
68020 and above
ECS & AGA chipset
0.5..2Mb chipmem + 0..∞ fastmem
From the question, I'm not sure how experienced you are with Amiga programming. If you have zero experience with the way windows and screens are set up, then I can strongly recommend Anders Bjerin's Amiga C Manual
It's fairly old and predates AGA, but it shouldn't be a huge problem to extrapolate how to open a 256 colour screen.
I currently work in a customer assignment related to performance problems in a WPF rich client LOB application.
The problem is that the application runs very slow/sluggish. Especially data table handling (scrolling, sorting, selection) is extremely slow and leaves the application unusable.
I analyzed the system state when a single tab containing a few textboxes, comboboxes and labels is opened and left idle (waiting for user input).
These are my findings:
All the rendering is calculated on the GPU
There are no performance heavy features such as animations, bitmap effects, transparency, etc.
When the tab is idle (only the cursor is blinking in the focused textbox, the rest of the tab is static and does not even contain any data) the GPU runs up to 90%
GPU drops to 0 whenever the tab loses focus
GPU percentage directly relates to the window size. A small window brings it down to a few percent, full screen makes it go up to almost 100%
WPF Perforator tells me that WPF calculates the dirty region for the entire tab instead of only the blinking cursor
WPF Perforator reports dirty rect update rates larger than 20/sec on the idle tab and they directly correlate to GPU usage
My conclusion:
During development a lot of custom code (layout, event handling, etc..) has been introduced in order to fit WPF to the backend-driven architecture of the system as a whole. My guess is that due to some of the custom code the dirty-rect-mechanism of WPF has been broken. This leads to too much drawing activity and thus very high GPU usage. These innecessary activities lead to the problems described above.
Now I am looking for any advice where I should start my investigation. Or in other words: What are typical mistakes that a developer can make in order to break the WPF dirty-rect update algorithm. Any input is highly appreciated.
Many thanks and best regards!
Manuel
Thanks for the input. Let me clarify backend-driven: The UI is highly dynamic. A message from the backend defines the structure of the ui and the data to be displayed. Therefore, we do not have any xaml for the structure of the tabs, only c#.
In the meantime, I could solve the problem. I used Snoop and collapsed every element one by one while monitoring GPU usage. I found out that there was a very tiny pixelshader effect (DropShadowEffect) on one of the borders. As soon as I removed the effect, the GPU dropped from 80% to 1%. WPF drew correct dirty rectangles over small portions of the UI. Problem solved, case closed.
Things that seem interesting to me:
1. The tremendous impact that this small effect has on the GPU usage.
2. That it breaks the dirty-rect calculation.
3. Since it was not a BitmapEffect but a PixelshaderEffect I could not reveal it by disabling BitmapEffects in Perforator.
Thanks!
MM