Closed Bug 911133 Opened 11 years ago Closed 6 years ago

[tracking] Split winrt and gecko thread logic

Categories

(Core Graveyard :: Widget: WinRT, defect, P1)

Product:
Core Graveyard
Component:
Widget: WinRT
Platform:
x86_64
Windows 8.1
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jimm, Unassigned)

References

Details

(Keywords: meta, Whiteboard: [tracking])

Attachments

(1 file, 1 obsolete file)

prelim method notes
16.45 KB, patch
Details | Diff | Splinter Review 
See bug 907410 for the details. What we want to do is have two main threads, one for winrt which handles processing of input, and one for gecko. This is a v2 goal.
One issue here is accessibility which will try to access the dom on the winrt thread. We'll need to proxy these calls which is unfortunate since the winrt thread will have to block on the gecko thread. Independent of this issue though I think the two threads will be able to run independently. 

This should also help solve our remaining re-entrancy problems brought to light in bug 914331.
Depends on: 741750
Guys, we should get this on the q1 radar. This will improve responsiveness for things like scrolling, and will fix the delay problems we have when swiping ion the nav bar and tab tray.
Blocks: metrobacklog
Note that if you enable content processes, this basically becomes bug 930939.
Whiteboard: [feature] p=0
Blocks: metrofxe10s
Blocks: 877672
Assignee: nobody → jmathies
Target Milestone: --- → mozilla30
Whiteboard: [feature] p=0 → [feature] p=20
OS: Windows 8 Metro → Windows 8.1
Priority: -- → P2
Version: 26 Branch → Trunk
No longer depends on: 741750
We need to split this bug for point estimation. Does the following separation make sense?
  A) One bug: Create the infrastructure to make synchronous and asynchronous calls from the OS input thread to the gecko thread.
  B) One bug: Convert all existing OS events to use the synchronous infrastructure.
  C) Multiple bugs for converting individual (or groups of) events to asynchronous.

The work we do here could also be used in desktopFx on Windows. Maybe we should have a desktopFx bug to parallel this one?
We don't have a good track record with 13 point and larger estimated bugs.  When this bug comes up we will need to break it down - even at some milestone level.
Whiteboard: [feature] p=20 → [feature] p=0
Whiteboard: [feature] p=0 → p=0 r=ff30
Target Milestone: mozilla30 → ---
Depends on: 974901
Attached patch prelim method notes (obsolete) — — Splinter Review 
Going through and itemizing thread access. This patch isn't for landing.

        Attachment #8379009 -
        Attachment is obsolete: true

    
  
Depends on: 974989

    
  
No longer depends on: 974901

    
  
No longer depends on: 974989

    
  
Depends on: 975452
Priority: P2 → P1
Whiteboard: p=0 r=ff30 → p=0

    
  
Assignee: jmathies → nobody

    
  
Keywords: meta
Summary: Split winrt and gecko thread logic → [tracking] Split winrt and gecko thread logic
Whiteboard: p=0 → [tracking]

    
    

    
  
We never shipped the metro support, closing!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: