[FlattenPictureTest] Not all tests succeed

[laplace]

Not all tests of the test application FlattenPictureTest succeed.

The following tests fail:

• Fill/StrokeArc
• Fill/StrokeBezier
• FillRegion
• Fill/StrokeTriangle
• Nested Picture recording -> ticket #1382

Test DrawString does not fail, but the resulting bitmap is not always displayed correctly. See attachment.

Please let me know if you want a bug report for each test (or group of related tests) that fails.

For reference the source code is in tests/kits/interface/flatten_picture.

[laplace]

Screenshot of test results

[jackburton]

I've added some missing ops in hrev21918 and fixed the wrong drawing in hrev21919. I've no idea yet as some ops (stroke round rect, drawchar, stroke triangle, and sometimes others) sometimes fail.

[jackburton]

I've implemented drawing of BPictures inside BPictures in hrev21920. Everything seems to work now, except AppendToPicture(), and the random missing ops.

I've noticed one thing, though: the test usually takes a really long amount of time to execute, at least on vmware. The few times when the test runs fast, everything seems to work. Could this be related to some bug in communication between the app_server and libbe ? I noticed I have some old TODO in the code. Can someone review for example the commented code in ServerPicture::ImportData() to see if I did something wrong ?

[laplace]

Thanks a lot! BTW showing a printed page in Preview still displays an empty page, I guess it's time to check my own code ;-) But I will wait first for AppendToPicture() to be implemented :-)

About the long execution time: Each test is performed eight times: four different color_spaces for flatten/unflatten and archive/unarchive. The tests are also not optimized. For example the bitmap for offscreen rendering is created for each test. At least under BeOS this is a very slow operation and could be speed up by caching the offscreen bitmap.

There is a second menu item (ALT+S) for running the tests only in color_space B_RGB32.

[jackburton]

Replying to laplace:

Thanks a lot! BTW showing a printed page in Preview still displays an empty page, I guess it's time to check my own code ;-) But I will wait first for AppendToPicture() to be implemented :-)

Note that there are still 2 missing ops: B_PIC_SET_CLIP_RECTS (BView's SetClipping()) (for which I've no documentation yet) and B_PIC_CLIP_TO_PICTURE (BView's ClipToPicture())

Not sure if they're needed for printing.

I'm also still trying to find out the cause of the random missing ops.

[laplace]

I think the print_server itself does not use the clipping functions, but printer drivers could use it. Anyway an application that is able to print is for sure allowed to use them.

I have added more tests. The following fail:

• ConstrainClippingRegion
• SetPenSize: Pen size of 0 is not drawn as if it had size of 1
• SetPenSize2: Scaling is not applied to the pen size
• TestPattern: pattern seems not to be taken into account

The following do not create the correct bitmap:

• ClipTo[Inverse]Picture

ConstrainClippingRegion and ClipTo[Inverse]Picture are documented here: ​http://www.beunited.org/bebook/The%20Interface%20Kit/ViewGraphicsState.html

[jackburton]

Replying to laplace:

I think the print_server itself does not use the clipping functions, but printer drivers could use it. Anyway an application that is able to print is for sure allowed to use them.

I have added more tests. The following fail:

• ConstrainClippingRegion
• SetPenSize: Pen size of 0 is not drawn as if it had size of 1
• SetPenSize2: Scaling is not applied to the pen size
• TestPattern: pattern seems not to be taken into account

Thanks, I'll try to fix these problems.

The following do not create the correct bitmap:

• ClipTo[Inverse]Picture

ClipToPicture is not even implemented as a "normal" op (outside of BPicture, I mean). I think this should be a different bug ("ClipToPicture not implemented");

ConstrainClippingRegion and ClipTo[Inverse]Picture are documented here: ​http://www.beunited.org/bebook/The%20Interface%20Kit/ViewGraphicsState.html

Sorry, I didn't explain correctly: I meant I don't have any docs about how the SetClipRects op (ConstrainClippingRegion) is encoded in BPicture data.

[jackburton]

Replying to laplace:

I have added more tests. The following fail:

• ConstrainClippingRegion
• SetPenSize: Pen size of 0 is not drawn as if it had size of 1

I read the documentation, but I'm not sure where we should handle that. The docs say: "The default pen size is 1.0 coordinate unit. It can be set to any nonnegative value, including 0.0. If set to 0.0, the size is translated to one pixel for all devices. This guarantees that it will always draw the thinnest possible line no matter what the resolution of the device.

Thus, lines drawn with pen sizes of 1.0 and 0.0 will look alike on the screen (one pixel thick), but the line drawn with a pen size of 1.0 will be 1/72 of an inch thick when printed, however many printer pixels that takes, while the line drawn with a 0.0 pen size will be just one pixel thick. "

• SetPenSize2: Scaling is not applied to the pen size

• TestPattern: pattern seems not to be taken into account

This is fixed in hrev21937.

I have another question: I've noticed that the colors of the test results change in a weird way, when I click on them. For example, the pattern test looks like it has only the central rect filled with pattern. Since this happens also with the "direct" drawing, I don't think it's a bug in the picture implementation. What do you think ?

[laplace]

Replying to jackburton:

Replying to laplace:

• SetPenSize: Pen size of 0 is not drawn as if it had size of 1

I read the documentation, but I'm not sure where we should handle that. The docs say: "The default pen size is 1.0 coordinate unit. It can be set to any nonnegative value, including 0.0. If set to 0.0, the size is translated to one pixel for all devices. This guarantees that it will always draw the thinnest possible line no matter what the resolution of the device.

Thus, lines drawn with pen sizes of 1.0 and 0.0 will look alike on the screen (one pixel thick), but the line drawn with a pen size of 1.0 will be 1/72 of an inch thick when printed, however many printer pixels that takes, while the line drawn with a 0.0 pen size will be just one pixel thick. "

OK, forgot about that.

• SetPenSize2: Scaling is not applied to the pen size

• TestPattern: pattern seems not to be taken into account

This is fixed in hrev21937.

Great!

I have another question: I've noticed that the colors of the test results change in a weird way, when I click on them. For example, the pattern test looks like it has only the central rect filled with pattern. Since this happens also with the "direct" drawing, I don't think it's a bug in the picture implementation. What do you think ?

Yes, I have realized that too. I did want to create a ticket after further examination. The rendering results are stored in BBitmaps and drawn to the window with DrawBitmap(), so I suppose either there is a bug or the bitmap is not setup correctly (color_space?) or drawn with wrong drawing mode etc... however it works fine under BeOS.

There is also another issue (will also create a ticket later). The header line in the window is truncated. If you maximize the window not the complete text is displayed.

[jackburton]

Replying to laplace:

Yes, I have realized that too. I did want to create a ticket after further examination. The rendering results are stored in BBitmaps and drawn to the window with DrawBitmap(), so I suppose either there is a bug or the bitmap is not setup correctly (color_space?) or drawn with wrong drawing mode etc... however it works fine under BeOS.

Michael, what's the status of this bug ? I can see that only the clipping region test is failing regularily. Some other tests are failing randomly, though. Do you have any hint to what could be causing this ?

[laplace]

I have no idea what's causing this. However I suppose its a Haiku bug, since this does not happen under BeOS.

The following tests still fail always:

• SetPenSize - the line with size 0 is not drawn
• SetPenSize2 - the line with size 4 before scaling with 0.5 is not drawn

These tests do not fail, but the result is not rendered correctly:

• DrawLargeBitmap - the 1024x768 bitmap is not drawn

BTW I have fixed the issue drawing the results. Actually this is a workaround. Now the drawing mode is set to B_OP_COPY in TestResultItem::DrawItem() before any drawing operations.

[jackburton]

Replying to laplace:

I have no idea what's causing this. However I suppose its a Haiku bug, since this does not happen under BeOS.

The following tests still fail always:

• SetPenSize - the line with size 0 is not drawn
• SetPenSize2 - the line with size 4 before scaling with 0.5 is not drawn

I fixed these in hrev22213 and hrev22215 respectively.

These tests do not fail, but the result is not rendered correctly:

• DrawLargeBitmap - the 1024x768 bitmap is not drawn

I suspect this is due to the bitmap data not being correctly passed via ports (port capacity limit, I'd guess).

BTW I have fixed the issue drawing the results. Actually this is a workaround. Now the drawing mode is set to B_OP_COPY in TestResultItem::DrawItem() before any drawing operations.

That's good. But that means there is a bug in haiku :)

[stippi]

Replying to jackburton:

Replying to laplace:

These tests do not fail, but the result is not rendered correctly:

• DrawLargeBitmap - the 1024x768 bitmap is not drawn

I suspect this is due to the bitmap data not being correctly passed via ports (port capacity limit, I'd guess).

AFAIK, BBitmap data is not passed through ports yet (it could be for small bitmaps maybe). Shared memory is used.

[jackburton]

Replying to stippi:

AFAIK, BBitmap data is not passed through ports yet (it could be for small bitmaps maybe). Shared memory is used.

Yes but BPictures store the raw bitmap data in the picture data stream, and when it's passed to the client for archiving, for example, that data DOES pass through ports.

[jackburton]

also see #1067

[jackburton]

I tried the FlattenPictureTest recently, here are the results:

In RGB32 mode, only two tests are failing:

• Record and play picture with offset
• Set Clipping

The former worked, and started failing only lately (maybe after Julun's hrev24682, but I'm not sure).

The latter never worked, I have no idea why. I double checked the code involved and it seems correct: the op is correctly written to the picture stream, and played correctly by PicturePlayer. So if there's a problem, could be in the code which sets the clipping region.

The tests made in other color spaces seem to fail randomly, can't understand why, but it doesn't seem related to BPicture.

Also, the large bitmap test doesn't draw anything, not even in direct drawing mode.

P.S: the tests now run very fast.

[julun]

Hi,

where do i find these tests? Any advice on how to get them on the image, important things to know, etc?

Thanks, Karsten

[jackburton]

Replying to julun:

Hi,

where do i find these tests? Any advice on how to get them on the image, important things to know, etc?

Thanks, Karsten

To get the tests on the image, add this line to your UserBuildConfig

AddFilesToHaikuImage home : FlattenPictureTest ;

(it will be copied to your home folder in the image)

The test app itself is in src/tests/kits/interface/flatten_picture

[julun]

Hi,

i did some short test with and without my change, also on R5. Strange thing here is that with my chage Direct Drawing does the same as on R5, but the rest is still wrong. Without my change the test seems to succeed, because Direct Drawing seems to fail? I find it also strange that a bunch of tests fail on R5, how can we be sure that we do the right thing? Also, e.g if direct drawing is broken, how are we supposed to test against it?

Find attached an screenshot done hrev5, without, with my change.

Karsten

[julun]

I get an trac crash or something while adding the screeshot. One can get it here:

​http://www.julun.de/haiku/R5-Picture-Test.png

Karsten

[jackburton]

Thanks! With your tests and observations, I was able to find the problem. The problem is that the tests use nested BPictures, so it wasn't the drawing of BPictures at an offset which was broken, but the drawing of BPictures inside BPictures. Wait for the fix. Thanks!

[jackburton]

That problem is fixed in hrev27267.

[stippi]

Generating a clipping region from a BPicture is not implemented at all, yet. For the time being, it may be a solution to generate a BRegion with the brute force method - draw the picture into a bitmap (1bpp) and then BRegion::Include() each pixel that has a value of 1. If you loop over the pixels with the outer loop iterating y and the inner loop iterating x from left to right, the resulting BRegion will at least constructed with the best efficiency. From what I remember with talking with one of the previous Be engineers, this should be the same thing in essence what the BeOS app_server did.

[jackburton]

Replying to stippi:

Generating a clipping region from a BPicture is not implemented at all, yet. For the time being, it may be a solution to generate a BRegion with the brute force method - draw the picture into a bitmap (1bpp) and then BRegion::Include() each pixel that has a value of 1. If you loop over the pixels with the outer loop iterating y and the inner loop iterating x from left to right, the resulting BRegion will at least constructed with the best efficiency. From what I remember with talking with one of the previous Be engineers, this should be the same thing in essence what the BeOS app_server did.

Yeah, I know that, but this is a different problem (see bug #1397).

[stippi]

But at least I meant exactly this problem, is the failing test something else? Anyways, I cannot look at the attachment, seems to be a Trac problem...

[jackburton]

Replying to stippi:

But at least I meant exactly this problem, is the failing test something else? Anyways, I cannot look at the attachment, seems to be a Trac problem...

Sorry, I did not explain the problem correctly: The problem currently is that the SetClippingRegion test fails. The direct drawing test constructs a BPicture, does a SetClippingRegion() on it, and calls FillRect (AFAIR). the second test constructs a BPicture, does the same as above, and constructs a BPicture with all this (thus "nesting" the DrawPicture call). This is what is failing.

[laplace]

Does anybody want to add test cases for drawing mode, blending mode, line mode, push/pop state, move pen, set font?

[jackburton]

Replying to laplace:

Does anybody want to add test cases for drawing mode, blending mode, line mode, push/pop state, move pen, set font?

I can do that while researching this bug (I think I found the problem(s)).

[jackburton]

Replying to jackburton:

Replying to laplace:

Does anybody want to add test cases for drawing mode, blending mode, line mode, push/pop state, move pen, set font?

I can do that while researching this bug (I think I found the problem(s)).

Ok, looks like that the client part is okay. Server side there's still a problem but I can't find what happens. I tried to change the set_clipping_rects command to fill_rect (in ServerPicture.cpp) and the rects are filled correctly, so it isn't a problem of wrong coordinates. Stippi ? Any idea ?

[jackburton]

I fixed this last problem (but since Berlios is down I can't commit). Now all tests passes, except SetDrawingMode(). Actually it looks like the test passes, but the last image (which is the result of the direct drawn bitmap 'minus' the BPicture drawn bitmap) looks weird. I have no idea why.

[jackburton]

The last problem is fixed in hrev32087. Closing.