Regression: Lag issue since PRO-B4

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start the XMB
2. Move around the XMB
3. See any movie entry for a ISO

What is the expected output?
Smooth transition between xmb items, fluid video reproduction.

What do you see instead?
Severe lag when moving around the XMB items and slower video intro in ISO 
images.

What version of the product are you using? On what operating system?
Tested with PRO-B7 and 5c7f81084a2d changeset.

Please provide any additional information below.

This bug was introduced some days before the B4 release since B3 didn't has the 
issue. I made a bisect of the code and found this (starting from the B4 tag):

code@hatsune procfw % hg bisect --reset
code@hatsune procfw % hg bisect --bad
code@hatsune procfw % hg bisect --good 2b9cbed77cdd
Testing changeset 631:5611a0a2bf43 (163 changesets remaining, ~7 tests)
84 files updated, 0 files merged, 22 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --good             
Testing changeset 671:073c7a10ed6f (82 changesets remaining, ~6 tests)
78 files updated, 0 files merged, 0 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --good 
Testing changeset 691:6fc88163d6cf (41 changesets remaining, ~5 tests)
16 files updated, 0 files merged, 0 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --good                                         
Testing changeset 701:c826743bcdf1 (21 changesets remaining, ~4 tests)
18 files updated, 0 files merged, 0 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --bad  
Testing changeset 697:e359844c06ab (10 changesets remaining, ~3 tests)
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --bad
Testing changeset 693:d0f2aaff0048 (5 changesets remaining, ~2 tests)
8 files updated, 0 files merged, 6 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --good
Testing changeset 695:b5048cb6a58d (3 changesets remaining, ~1 tests)
9 files updated, 0 files merged, 0 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --skip
Testing changeset 696:38cb3bb4a5b6 (3 changesets remaining, ~1 tests)
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
code@hatsune procfw % hg bisect --bad 
Due to skipped revisions, the first bad revision could be any of:
changeset:   695:b5048cb6a58d
parent:      693:d0f2aaff0048
user:        Hrimfaxi <outmatch@gmail.com>
date:        Fri Apr 01 19:02:34 2011 +0800
summary:     Stargate: added psid_check

changeset:   696:38cb3bb4a5b6
user:        coldbird
date:        Fri Apr 01 19:00:22 2011 +0200
summary:     Fixed Inverse Binary Preprocessor Logic for PSID Check.

Since the b5048cb6a58d changeset didn't compile, that leaves us with 
38cb3bb4a5b6. The bug is caused by a lot of get_thread_id calls inside the 
_sceCtrlReadBufferPositive function from Vshctrl/vshmenu.c. These calls are 
very expensive since they call sceKernelGetThreadmanIdList and do a loop to 
check a lot of threads.

My solution involves moving the least expensive (and more important) check to 
the top of the checkslist, and that is the button press. I tested it and now 
the XMB movement is smooth again.

The attached patch applies cleanly to the 5c7f81084a2d changeset.

Original issue reported on code.google.com by codestat...@gmail.com on 30 Jun 2011 at 12:50

Attachments:

• procfw-5c7f81084a2d_fix_xmb_lag.patch

[GoogleCodeExporter]

That's great. Patch accepted. Thanks for your work.

Original comment by outma...@gmail.com on 30 Jun 2011 at 3:19

[GoogleCodeExporter]

Original comment by outma...@gmail.com on 30 Jun 2011 at 3:30

• Changed state: Fixed