Reverting pipe stuff 501 #18362
Reverting pipe stuff 501 #18362
Conversation
|
@TurboGit, @jenshannoschwalm do you want me to test this too? |
|
@wpferguson : Yes please would be good to be sure that all is ok on 5.0.1 especially since I plan to cut the sources this week-end. TIA. |
|
I processed 47 images and got stuck in the "working" loop 4 times. My setup was clone master, checkout release-5.0.0, pull the PR and apply it, compile and test. Is this an accurate way to test or should I have done something different? |
|
It is the correct way. This is possibly one of the expose loops that has been fixed in master. Could you provide a log? |
|
-d screen isn't a valid flag |
|
|
|
I guessed right :-D, here you go.... Stopped after the error occurred, so work backwards from the end EDIT: Every time the loop occurred it was after I loaded the image and the style was applied, but before I started any processing. EDIT 2: Here's another one, |
|
Yes, exactly. That's the dimension recalculating i guess. I will have a look over the next 2 days - not sure if we can fix that with one safe commit. Maybe you'll have to test again :-) My guess would be f89705c you might cherry pick and test. If i remember correctly that was done while investigating these type of loops. |
|
Here you go for testing |
|
Processed 12 images, got a loop. EDIT: Processed 16 more, another loop, |
|
Both logs don't show that ??? |
|
Sorry, forgot the flags. I had it baked into the command earlier. |
|
With logging on I can't reproduce. Processed 55 images without a problem. |
|
Kept testing, finally reproduced. |
|
Aah, yes. I am sure this is not related to the original issue you bisected. For me it's a redrawing issue requesting a new dimension calculation. Unfortunately no idea how that is triggered or how/where to fix. Can you confirm, that the added commit is at least making this a lot more stable from your testing? |
|
With logging on it's very hard to reproduce. Without logging it occurs more often, but still less than it was. I think a "normal" user probably isn't going to experience this, I do have some ideas about what is happening that I would like to test out (things I'm doing, not pixelpipe code). All in all, I think it's good for 5.0.1. |
This reverts commit 48282d4. Some static fixes for iop_order
This reverts commit e8c2b95.
As the hash is based upon position in the pipe - this is not iop_order - we have to find and use that.
Only enabled pieces/modules should be integrated into the hash
dt_dev_pixelpipe_change() calls the possibly costly dt_dev_pixelpipe_get_dimensions() in all cases in addition to possibly syncing pipe nodes. In dt_dev_process_image_job() we check for situations where we *must* call dt_dev_pixelpipe_change() as we don't have the pipe dimensions available in addition to pipe->changed != DT_DEV_PIPE_UNCHANGED. This leads to a significant performance gain due to less "pixelpipe-runs" just done to get the dimension. In dt_dev_pixelpipe_change() we reduce the amount of syncing if possible as there is another active dt_dev_pixelpipe_change_t flag that includes work to be done. Some log improvements reducing misleading noise.
jenshannoschwalm
force-pushed
the
reverting_pipe_stuff_501
branch
from
26dea41 to
98d2505
Compare
No description provided.