summaryrefslogtreecommitdiffstats
path: root/content/port
Commit message (Collapse)AuthorAgeFilesLines
* Revert 142541 - Drop frontbuffers with ui-use-gpu-process, synchronized with ↵nkostylev@chromium.org2012-06-181-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | browser, decoupled from backbuffer drop. Reason (speculative): According to http://build.chromium.org/p/chromium.chromiumos/builders/ChromiumOS%20%28amd64%29/builds/2556 http://build.chromium.org/p/chromium.chromiumos/builders/ChromiumOS%20%28x86%29/builds/6039 after this commit those bots startet faling VMTest stage. On Aura, every time a tab is backgrounded, RenderWidgetHostViewAura will reset its handle to the front surface. If that tab is foregrounded again, that front surface will not be used until synchronizing with the gpu process to make sure that surface is still available. By doing this, the gpu process knows when it is safe to discard the front surface. RWHVA sends a FrontSurfaceIsProtected(bool, int) message to the gpu process to keep it informed about front surface protection. The int is a state-of-the-world identifier to protect from ABA issues. RWHVA delays sending FrontSurfaceIsProtected(false) until after the current surface is certain to not be in use, namely after the compositor finishes the current frame and the browser thumbnailer is complete. BUG=112842 TEST=Manual Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=142408 Review URL: https://chromiumcodereview.appspot.com/10052018 TBR=mmocny@chromium.org Review URL: https://chromiumcodereview.appspot.com/10563021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142692 0039d316-1c4b-4281-b951-d872f2087c98
* Drop frontbuffers with ui-use-gpu-process, synchronized with browser, ↵mmocny@chromium.org2012-06-161-1/+2
| | | | | | | | | | | | | | | | | | | decoupled from backbuffer drop. On Aura, every time a tab is backgrounded, RenderWidgetHostViewAura will reset its handle to the front surface. If that tab is foregrounded again, that front surface will not be used until synchronizing with the gpu process to make sure that surface is still available. By doing this, the gpu process knows when it is safe to discard the front surface. RWHVA sends a FrontSurfaceIsProtected(bool, int) message to the gpu process to keep it informed about front surface protection. The int is a state-of-the-world identifier to protect from ABA issues. RWHVA delays sending FrontSurfaceIsProtected(false) until after the current surface is certain to not be in use, namely after the compositor finishes the current frame and the browser thumbnailer is complete. BUG=112842 TEST=Manual Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=142408 Review URL: https://chromiumcodereview.appspot.com/10052018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142541 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 142408 - Drop frontbuffers with ui-use-gpu-process, synchronized with ↵mmocny@chromium.org2012-06-151-2/+1
| | | | | | | | | | | | | | | | | | | | browser, decoupled from backbuffer drop. On Aura, every time a tab is backgrounded, RenderWidgetHostViewAura will reset its handle to the front surface. If that tab is foregrounded again, that front surface will not be used until synchronizing with the gpu process to make sure that surface is still available. By doing this, the gpu process knows when it is safe to discard the front surface. RWHVA sends a FrontSurfaceIsProtected(bool, int) message to the gpu process to keep it informed about front surface protection. The int is a state-of-the-world identifier to protect from ABA issues. RWHVA delays sending FrontSurfaceIsProtected(false) until after the current surface is certain to not be in use, namely after the compositor finishes the current frame and the browser thumbnailer is complete. BUG=112842 TEST=Manual Review URL: https://chromiumcodereview.appspot.com/10052018 TBR=mmocny@chromium.org Review URL: https://chromiumcodereview.appspot.com/10557014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142432 0039d316-1c4b-4281-b951-d872f2087c98
* Drop frontbuffers with ui-use-gpu-process, synchronized with browser, ↵mmocny@chromium.org2012-06-151-1/+2
| | | | | | | | | | | | | | | | | decoupled from backbuffer drop. On Aura, every time a tab is backgrounded, RenderWidgetHostViewAura will reset its handle to the front surface. If that tab is foregrounded again, that front surface will not be used until synchronizing with the gpu process to make sure that surface is still available. By doing this, the gpu process knows when it is safe to discard the front surface. RWHVA sends a FrontSurfaceIsProtected(bool, int) message to the gpu process to keep it informed about front surface protection. The int is a state-of-the-world identifier to protect from ABA issues. RWHVA delays sending FrontSurfaceIsProtected(false) until after the current surface is certain to not be in use, namely after the compositor finishes the current frame and the browser thumbnailer is complete. BUG=112842 TEST=Manual Review URL: https://chromiumcodereview.appspot.com/10052018 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@142408 0039d316-1c4b-4281-b951-d872f2087c98
* Add IPC argument to handle composition character bounds into ↵nona@chromium.org2012-06-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ViewHostMsg_ImeCompositionRangeChanged. What for: Using this argument, browser can acquire the composition character boundary rectangles. This information is used by Japanese input method editor to show its window at the correct position. This is used not only for fixing http://crbug.com/120597 but also for supporting IMR_QUERYCHARPOSITION message in Windows Chrome. To support IMR_QUERYCHARPOSITION(Ref 1) message, input method editor can also show its window at the correct position(Ref 2). Performance: There is no performance concern for latin language users because this IPC is only emitted if the user uses an input method editor. Even if the user uses an input method editor, the cost of this IPC is small because this IPC will be emitted at the same frequency as key typing. Data size: The data size to be transferred is small: it is the composition string length (typically less than a few dozen characters) times sizeof(gfx::Rect). Ref 1. http://msdn.microsoft.com/en-us/library/windows/desktop/dd318634(v=vs.85).aspx Ref 2. https://bug-87911-attachments.webkit.org/attachment.cgi?id=144954 (In Ref2, Safari works well for all IMEs. Firefox works well except ATOK. Chrome doesn't work for all IMEs.) BUG=120597 TEST=try bots. Review URL: https://chromiumcodereview.appspot.com/10543024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141866 0039d316-1c4b-4281-b951-d872f2087c98
* mac: Remove GetViewCocoaBounds()thakis@chromium.org2012-06-071-6/+0
| | | | | | | | | | | | | | | | | | | The decision is to keep almost all IPC messages in view units, and only use pixels in the BackingStore object instead. Change RenderWidgetHostViewMac::GetViewBounds() to return (0, 0, w, h) instead of (0, 0, 0, 0). This matches the GTK code, and matches what rwh got from rwhvmac before this patch. Needed for PrerenderBrowserTest.PrerenderWindowSize BUG=31960 TEST=none Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=141024 Review URL: https://chromiumcodereview.appspot.com/10541047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141079 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 141024 (caused PrerenderBrowserTest.PrerenderWindowSize to fail??)thakis@chromium.org2012-06-071-0/+6
| | | | | | | | | | | | | | | | | - mac: Remove GetViewCocoaBounds() The decision is to keep almost all IPC messages in view units, and only use pixels in the BackingStore object instead. BUG=31960 TEST=none Review URL: https://chromiumcodereview.appspot.com/10541047 TBR=thakis@chromium.org Review URL: https://chromiumcodereview.appspot.com/10540061 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141039 0039d316-1c4b-4281-b951-d872f2087c98
* mac: Remove GetViewCocoaBounds()thakis@chromium.org2012-06-071-6/+0
| | | | | | | | | | | | The decision is to keep almost all IPC messages in view units, and only use pixels in the BackingStore object instead. BUG=31960 TEST=none Review URL: https://chromiumcodereview.appspot.com/10541047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@141024 0039d316-1c4b-4281-b951-d872f2087c98
* Multi-select <select> in 'external popup window'aruslan@chromium.org2012-05-261-0/+15
| | | | | | | | | | | | | | We use an 'external popup window' for both single and multi selection <select> tag popups. This also supports <optgroup> and disabled <option> items and multiple selections. On all other chrome platforms a multi-select <select> tag is rendered in page, so this CL adds a bit of plumbing and IPC stuff to get the multi-select popups working as well. WebKit side of this CL is at http://trac.webkit.org/changeset/94600 Review URL: https://chromiumcodereview.appspot.com/10436010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@139169 0039d316-1c4b-4281-b951-d872f2087c98
* Move RenderViewHostDelegate::View to content/port and rename it to ↵jam@chromium.org2012-05-241-0/+59
| | | | | | | | | RenderViewHostDelegateView. This only needs to be seen by embedders who override WebContentsView. As a result, WebContentsView doesn't derive from it anymore. BUG=98716 Review URL: https://chromiumcodereview.appspot.com/10441009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138799 0039d316-1c4b-4281-b951-d872f2087c98
* Makes the browser send pixels to the GPU process where it should.pkotwicz@chromium.org2012-05-231-4/+4
| | | | | | | | | | | | | | | | | This patch fixes the places where we will be sending DIP to the GPU process but should be sending pixels instead to the GPU process once https://bugs.webkit.org/show_bug.cgi?id=86051 lands. This patch reverts: http://codereview.chromium.org/127553/ http://codereview.chromium.org/10332077/ Bug=127455, 114677 Test=Manual SchedulePaintInRect is called with parameters in DIP TBR=piman@chromium.org,sky@chromium.org,jamesr@chromium.org Review URL: https://chromiumcodereview.appspot.com/10411086 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138510 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 138415 - Makes the browser send pixels to the GPU process where it ↵pkotwicz@chromium.org2012-05-231-4/+4
| | | | | | | | | | | | | | | | | | | | | | should. This patch fixes the places where we will be sending DIP to the GPU process but should be sending pixels instead to the GPU process once https://bugs.webkit.org/show_bug.cgi?id=86051 lands. This patch reverts: http://codereview.chromium.org/127553/ http://codereview.chromium.org/10332077/ Bug=127455, 114677 Test=Manual SchedulePaintInRect is called with parameters in DIP TBR=piman@chromium.org,sky@chromium.org,jamesr@chromium.org Review URL: https://chromiumcodereview.appspot.com/10411086 TBR=pkotwicz@chromium.org Review URL: https://chromiumcodereview.appspot.com/10383297 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138419 0039d316-1c4b-4281-b951-d872f2087c98
* Makes the browser send pixels to the GPU process where it should.pkotwicz@chromium.org2012-05-231-4/+4
| | | | | | | | | | | | | | | | | This patch fixes the places where we will be sending DIP to the GPU process but should be sending pixels instead to the GPU process once https://bugs.webkit.org/show_bug.cgi?id=86051 lands. This patch reverts: http://codereview.chromium.org/127553/ http://codereview.chromium.org/10332077/ Bug=127455, 114677 Test=Manual SchedulePaintInRect is called with parameters in DIP TBR=piman@chromium.org,sky@chromium.org,jamesr@chromium.org Review URL: https://chromiumcodereview.appspot.com/10411086 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138415 0039d316-1c4b-4281-b951-d872f2087c98
* Defer CGLFlushDrawable until OSX-requested drawRect to avoid spinning when ↵jbates@chromium.org2012-05-221-0/+3
| | | | | | | | | | | | | | | | window is obscured. Sadly, this fix regresses some black flashing bugs: -flicker-test2.html occasionally flashes while resizing the window. I think this regression could be fixed if we always draw with the OpenGL context once the context is created. But that would be a third drawing path and some significant code, so let's consider it in a follow up. BUG=127709 TEST=open https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/particles/index.html ; open Activity Monitor and observe the chrome process CPU usage ; resize chrome window so it's smaller than the Activity Monitor window (or increase size of Activity Monitor); move Activity Monitor on top of chrome window to fully obscure it ; verify that the CPU usage of chrome does not spike upwards while the chrome window is obscured. Review URL: https://chromiumcodereview.appspot.com/10382213 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@138327 0039d316-1c4b-4281-b951-d872f2087c98
* Move NativeWebKeyboardEvent to the content namespace.jam@chromium.org2012-05-181-1/+4
| | | | | | | TBR=ben Review URL: https://chromiumcodereview.appspot.com/10383239 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137865 0039d316-1c4b-4281-b951-d872f2087c98
* Consolidate RenderWidgetHost::CopyFromBackingStore and ↵mazda@chromium.org2012-05-081-8/+4
| | | | | | | | | | | | | RenderWidgetHost::AsyncCopyFromBackingStore. This CL depends on http://codereview.chromium.org/10348007/. BUG=120003 TEST=Manual Review URL: https://chromiumcodereview.appspot.com/10352016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@135839 0039d316-1c4b-4281-b951-d872f2087c98
* ui: Move surface/ directory out of gfx/, up to ui/.tfarina@chromium.org2012-05-031-1/+1
| | | | | | | | | | BUG=104040 R=ben@chromium.org TBR=brettw@chromium.org Review URL: https://chromiumcodereview.appspot.com/10351002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@135232 0039d316-1c4b-4281-b951-d872f2087c98
* Delete background tab IOSurfaces on Mac.jbates@chromium.org2012-04-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | The deleting part is easy: just handle the AcceleratedSurfaceSuspend call by unrefing the IOSurface. The hard part is dealing with a NSView drawRect when we don't have the IOSurface (or software BackingStore). To solve this, I reuse the GetBackingStore code to wait for a new frame from the renderer. When the BuffersSwapped message arrives on the IO thread for Mac, an UpdateRect message is synthesized with the SwapBuffers data. The UpdateRect message wakes up the UI thread and allows GetBackingStore to resume. The accelerated path can have multiple frames in the pipeline, so it is rarely enough to just wait for the next UpdateRect. Instead, the GetBackingStore method is updated to wait up to 40ms to get the correctly-sized frame (whether it's accelerated or software). The original GetBackingStore code waits for a frame that matches current_size_. However, this CL makes GetBackingStore wait for a frame that matches the view_->GetViewBounds(). current_size_ is equal to the last UpdateRect, which may or may not match GetViewBounds. (Anyone know why the original code doesn't use GetViewBounds?) This allows us to recover from missing BackingStores or IOSurfaces if the renderer/GPU can produce a new frame within 40ms. We probably want to increase 40 to something like 60 or 100ms though because of the deep GPU pipeline. In addition, thanks to the blocking GetBackingStore, this fixes some additional bugs: - no more resize gutter jank on accelerated pages (Mac only for now, but should work on Windows with a followup patch). - no more white flash while resizing flicker-test2.html. BUG=117624,58782,85519,124328,106586 Review URL: https://chromiumcodereview.appspot.com/9980016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@134033 0039d316-1c4b-4281-b951-d872f2087c98
* Comments for RenderWidgetHostView Class Hierarchyscheib@chromium.org2012-04-111-0/+1
| | | | | | Review URL: https://chromiumcodereview.appspot.com/9960078 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131788 0039d316-1c4b-4281-b951-d872f2087c98
* Expose Mouse Lock and Fullscreen automation hooks to pyauto.scheib@chromium.org2012-04-111-5/+0
| | | | | | | | BUG=122479 Review URL: https://chromiumcodereview.appspot.com/10022010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131787 0039d316-1c4b-4281-b951-d872f2087c98
* Implement RenderWidgetHostViewMac::CopyFromCompositingSurface.mazda@chromium.org2012-04-111-2/+3
| | | | | | | | | | | | This adds the support of the browser side thumbailing to Mac Chrome. BUG=120001 TEST=Manually tested that thumbnails are properly generated on GPU composited pages with --enable-in-browser-thumbnailing. Review URL: http://codereview.chromium.org/10022007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131710 0039d316-1c4b-4281-b951-d872f2087c98
* Reland r131452: Add GLHelper::AsyncCopyTextureTo and make thumbnail ↵mazda@chromium.org2012-04-101-3/+12
| | | | | | | | | | | | | generation asynchronous. BUG=118547 TEST=Manually checked that UI thread is not blocked by the thumbnailer TBR=brettw,piman Review URL: http://codereview.chromium.org/10033008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131529 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 131452 - Add GLHelper::AsyncCopyTextureTo and make thumbnail ↵mazda@chromium.org2012-04-091-12/+3
| | | | | | | | | | | | | | | generation asynchronous. BUG=118547 TEST=Manually checked that UI thread is not blocked by the thumbnailer Review URL: http://codereview.chromium.org/9791031 TBR=mazda@chromium.org Review URL: https://chromiumcodereview.appspot.com/10024036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131456 0039d316-1c4b-4281-b951-d872f2087c98
* Add GLHelper::AsyncCopyTextureTo and make thumbnail generation asynchronous.mazda@chromium.org2012-04-091-3/+12
| | | | | | | | | | BUG=118547 TEST=Manually checked that UI thread is not blocked by the thumbnailer Review URL: http://codereview.chromium.org/9791031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@131452 0039d316-1c4b-4281-b951-d872f2087c98
* Remove TOOLKIT_USES_GTK and consolidate it into TOOLKIT_GTKoshima@chromium.org2012-04-051-2/+2
| | | | | | | | | | | Add gtk dependency to base.gyp for android host_os="linux" case BUG=none TEST=none Review URL: https://chromiumcodereview.appspot.com/9969080 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130784 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up a few TODO items.joi@chromium.org2012-03-221-0/+5
| | | | | | | | | | | | | | | | | | | | Push UnhandledWheelEvent and GetBrowserAccessibilityManager down to RenderWidgetHostViewPort. Get rid of OnMessageReceivedForTesting, in favor of RenderViewHostTester::TestOnMessageReceived (which already existed but needed to be converted to a static method so it could be used with regular RenderViewHost instances). Rename WebContentsTester::pending_rvh() to GetPendingRvh() since it's a virtual method. Remove top-level alias for content::RenderViewHostTestHarness and switch clients to use the fully-qualified name. Clean up a couple of other minor TODO items, some had already been done and the comment just needed to be removed; in one case the TODO was just wrong (in dump_accessibility_tree_browsertest.cc) since it's OK for content to depend on content implementations. Remove test_tab_contents.h from DEPS (seems to have been a merge failure in my last change that left this in). BUG=98716 Review URL: http://codereview.chromium.org/9838009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@128263 0039d316-1c4b-4281-b951-d872f2087c98
* Support browser side thumbnailing for GPU-composited pages on Windows.mazda@chromium.org2012-03-151-0/+6
| | | | | | | | | | | | | | | | | Benchmark results of copying a 1280 x 800 pixels using CopyFromCompositingSurface or CopyFromBackingSurface are as follows. FromCompositingSurface: 40.00 ms FromBackingStore: 2.12 ms I'm prepareing the following CLs and these will come soon, - Support Mac and Chrome OS (Aura) - Reduce the number of pixels to copy from the compositing surface for performance improvement BUG=96351 TEST=Manual Review URL: http://codereview.chromium.org/9582003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126870 0039d316-1c4b-4281-b951-d872f2087c98
* Add an OWNERS file for src\content by moving the owners that were there for ↵jam@chromium.org2012-03-141-3/+0
| | | | | | | | the top level directories within. I've removed them all from the subdirectories. Also removed the "set noparent" in subdirectories and just put one in src/content/OWNERS for now. I also added brettw/darin for src/chrome/OWNERS. Review URL: https://chromiumcodereview.appspot.com/9695028 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126522 0039d316-1c4b-4281-b951-d872f2087c98
* Move Render(View|Widget)Host and associated classes to content namespace.joi@chromium.org2012-03-071-1/+1
| | | | | | | | | TBR=jam@chromium.org BUG=98716 Review URL: https://chromiumcodereview.appspot.com/9600036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@125388 0039d316-1c4b-4281-b951-d872f2087c98
* Improve switch between gestures and touch mode when kEnableTouchEventsscottmg@chromium.org2012-03-031-1/+2
| | | | | | | | | | | | Mostly works, the only problem is that the first touch or gesture on switching "modes" gets lost because Windows doesn't start a touch of the "other" type when TouchRegisterWindow is called while there's a touch in progress. TBR=cpu Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=124813 Review URL: http://codereview.chromium.org/9549020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@124871 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 124813 - Improve switch between gestures and touch mode when ↵vandebo@chromium.org2012-03-031-2/+1
| | | | | | | | | | | | | | | kEnableTouchEvents Mostly works, the only problem is that the first touch or gesture on switching "modes" gets lost because Windows doesn't start a touch of the "other" type when TouchRegisterWindow is called while there's a touch in progress. TBR=cpu Review URL: http://codereview.chromium.org/9549020 TBR=scottmg@chromium.org Review URL: https://chromiumcodereview.appspot.com/9572033 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@124830 0039d316-1c4b-4281-b951-d872f2087c98
* Improve switch between gestures and touch mode when kEnableTouchEventsscottmg@chromium.org2012-03-031-1/+2
| | | | | | | | | | Mostly works, the only problem is that the first touch or gesture on switching "modes" gets lost because Windows doesn't start a touch of the "other" type when TouchRegisterWindow is called while there's a touch in progress. TBR=cpu Review URL: http://codereview.chromium.org/9549020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@124813 0039d316-1c4b-4281-b951-d872f2087c98
* Land 9348117: (Aura) use GPU process for UIbacker@chromium.org2012-02-241-1/+1
| | | | | | | | | | | | | This is behind a flag (--ui-use-gpu-process). Currently problems occur when the GPU process crash, this will be handled in a follow-up CL. BUG=99516 TEST=chrome --ui-use-gpu-process (with an aura build) TBR=sky,jam,apatrick Review URL: https://chromiumcodereview.appspot.com/9442017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@123473 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce content::RenderWidgetHostViewPort (in content/port/browser).joi@chromium.org2012-02-163-0/+266
Move RenderWidgetHostViewBase and TestRenderWidgetHostView to content namespace. Follow-up changes will move RenderWidgetHostView to content namespace, and get rid of content/browser/renderer_host/render_widget_host_view.h which is now just a redirect header. BUG=98716 Review URL: https://chromiumcodereview.appspot.com/9347042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@122288 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-13 19:10:58 +0000