diff --git a/src/steam/engine/buffer-provider.cpp b/src/steam/engine/buffer-provider.cpp index 8ebe9c9d3..bc09c9151 100644 --- a/src/steam/engine/buffer-provider.cpp +++ b/src/steam/engine/buffer-provider.cpp @@ -161,7 +161,7 @@ namespace engine { * may be emitted, and at most once. * @warning by convention, emitting a buffer implies that the contained data is ready and * might be used by other parts of the application. - * An emitted buffer should not be modified anymore. + * While an emitted buffer should not be modified anymore, it can still be accessed. */ void BufferProvider::emitBuffer (BuffHandle const& handle) diff --git a/src/steam/engine/turnout.hpp b/src/steam/engine/turnout.hpp index 9a8a5dbaa..b8aa9a79c 100644 --- a/src/steam/engine/turnout.hpp +++ b/src/steam/engine/turnout.hpp @@ -373,9 +373,9 @@ namespace engine { { REQUIRE (fanIn >= FAN_I and fanOut >= FAN_O); for (uint i=0; i(); + inParam[i] = & MAN::inBuff[i].template accessAs(); for (uint i=0; i(); + outParam[i] = & MAN::outBuff[i].template accessAs(); } void @@ -452,13 +452,22 @@ namespace engine { void weft (Feed& feed) { - /* NOP */ + feed.invoke(); } void fix (Feed& feed) { - /* NOP */ + for (uint i=0; i -
+
It turns out that --  throughout the render engine implementation -- we never need direct access to the buffers holding actual media data. Buffers are just some entity to be //managed,// i.e. "allocated", "locked" and "released"; the //actual meaning of these operations can be left to the implementation.// The code within the render engine just pushes around ''smart-prt like handles''. These [[buffer handles|BuffHandle]] act as a front-end, being created by and linked to a buffer provider implementation. There is no need to manage the lifecycle of buffers automatically, because the use of buffers is embedded into the render calculation cycle, which follows a rather strict protocol anyway. Relying on the [[capabilities of the scheduler|SchedulerRequirements]], the sequence of individual jobs in the engine ensures...
 * that the availability of a buffer was ensured prior to planning a job ("buffer allocation")
 * that a buffer handle was obtained ("locked") prior to any operation requiring a buffer
@@ -1265,7 +1265,7 @@ While BufferProvider is an interface meant to be backed by various and diverse k
 ;attaching
 :optionally the client may attach an object to a locked buffer. This object is placement-constructed into the buffer and will be destroyed automatically when releasing the buffer. Alternatively, the client may provide a pair of constructor- / destructor-functors, to be invoked in a similar way. This allows e.g. to install descriptor structures within the buffer, as required by an external media handling library.
 ;emitting
-:the client //may optionally mark a state transition// -- whose precise meaning remains implicit and implementation dependent. From the client's perspective, emitting and releasing may seem equivalent, since the buffer should not be touched after that point. However, conceivably there are usages where it matters for //the consumer// to be sure an expected result was actually achieved, since the producer may well acquire the buffer and then fail to complete the required work, prompting some clean-up safety mechanism to merely release the resources.
+:the client //may optionally mark a state transition// -- whose precise meaning remains implicit and implementation dependent. From the client's perspective, emitting and releasing may seem equivalent, since the buffer content should not be altered after that point. However, conceivably there are usages where it matters for //the consumer// to be sure an expected result was actually achieved, since the producer may well acquire the buffer and then fail to complete the required work, prompting some clean-up safety mechanism to merely release the resources.
 ;releasing
 :buffers need to be released explicitly by the client code. This renders the corresponding BuffHandle invalid, (optionally) invokes a destructor function of an attached object and maybe reclaims the buffer memory
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index 4f52ff41d..0f248961a 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -1500,9 +1500,7 @@
 
 
 
-  
-    
-  
+  
   
     

       ...könnte das am Ende nicht sinnvoll sein,
@@ -1535,9 +1533,7 @@
 
 
 
-  
-    
-  
+  
   
     

       wenn UI-Thread blockt/verhungert,
@@ -1661,9 +1657,7 @@
 
 
 
-  
-    
-  
+  
   
     

       in proc::asset::meta::theErrorLog_ID
@@ -1709,9 +1703,7 @@
 
 
 
-  
-    
-  
+  
   
     

       ...in den eigentlich kaputten DockManager
@@ -1832,9 +1824,7 @@
 
 
 
-  
-    
-  
+  
   
     

       brauchen wir diese zwischengeschaltete Methode showMsg()?
@@ -2168,9 +2158,7 @@
 
 
 
-  
-    
-  
+  
   
     

       ...das liegt vermutlich daran, daß ich die zweite Marke mit "right gravity" einfüge,
@@ -2990,9 +2978,7 @@
 
 
 
-  
-    
-  
+  
   
     

       "If widget exists: expand it, trigger its flash function (paint with timeout).
@@ -4502,9 +4488,7 @@
 
 
 
-  
-    
-  
+  
   
     

       ist nicht "die Session
@@ -6477,9 +6461,7 @@
 
 
 
-  
-    
-  
+  
   
     

       Begründung:
@@ -8864,9 +8846,7 @@
 
 
 
-  
-    
-  
+  
   
     

       expand() ruft eine vorbereitete Parametrisierung
@@ -14436,9 +14416,7 @@
 
 
 
-  
-    
-  
+  
   
     

       Komponente falls nötig anhängen
@@ -88056,8 +88034,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

        ☹
     

   
-
-
+
 
 
 
@@ -88072,8 +88049,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

       der Turnout ist ein Level-1-Builder....
     

   
-
-
+
 
 
 
@@ -88100,8 +88076,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

       mit der offensichtlichen forwarding-Impl
     

   
-
-
+
 
 
 
@@ -88117,6 +88092,36 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+
+  
+  
+    

+      gehe mal davon aus,
+    

+    

+      daß nach kompletter Berechnung
+    

+    

+      ein emitBuffer() erfolgen soll
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -127503,6 +127508,22 @@ std::cout << tmpl.render({"what", "World"}) << s
 
 
 
+
+
+  
+  
+    
    
+      
  • 
+        BufferProvider: Zugang zu Arbeits-Speicherblöcken
+      
    • 
+      
  • 
+        OutputManagement: verwalten von Datenströmen
+      
    • 
+    

+  
+
+
+
 
 
 
@@ -127512,6 +127533,45 @@ std::cout << tmpl.render({"what", "World"}) << s
 
 
 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  
+  
+    

+      Achtung: nicht idempotent
+    

+  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
 
@@ -129020,12 +129080,18 @@ std::cout << tmpl.render({"what", "World"}) << s
 
 
 
+
+
+
+
+
 
 
 
 
 
 
+